1.2 Proposal: Re-create "general task" from "topic"

Would it be useful for the main 
discussants to schedule a phone conference between now and the next TC 
meeting?


  
  
  From: Michael Priestley 
  [mailto:]
Sent: Wednesday, October 21, 2009 
  11:02 AM
To: Park Seth-R01164
Cc: DITA 
  TC
Subject: Re: [dita] 1.2 Proposal: Re-create "general task" from 
  "topic"


  
I did think about this, but there 
  are some real problems.

It will 
  mean either new element names for every existing task element (eg 
  <step>, <cmd>, etc.) in the ancestor, or a change to the class 
  attributes for those elements moved to the ancestor to reflect their new home 
  (eg <step class="+ topic/li generaltask/step ").

If we change the element names, none of the existing 
  stylesheet overrides for task will work for general task.

If we change the class names, none of the existing 
  stylesheet overrides will at all.

Also, specializers would need to include the ancestor generaltask.mod 
  in their specialization shells to create a valid doctype. If they just 
  included task.mod, it would create an error. So it's the same problem as with 
  constrained task (specialization shells are affected), except that the result 
  for unaware migrators would be a broken DTD rather than a looser task 
  model.

Michael Priestley, Senior 
  Technical Staff Member (STSM)
Lead IBM DITA Architect

http://dita.xml.org/blog/25



  
    
    
      From: 
      "Park Seth-R01164" 
        <> 
    
      To: 
      "DITA TC" 
        <> 
    
      Date: 
      10/21/2009 10:50 AM 
    
      Subject: 
      [dita] 1.2 Proposal: Re-create "general 
        task" from "topic"

  


The need for specialized expertise to sort 
  out local shell conflicts created from different domain (constraint or 
  otherwise) usage is unavoidable. However, the advent of general task is 
  pushing this conflict into the hands of the most basic users who 
  expect--rightly or not--that DITA can be used as an out-of-the box solution 
  without shell configuration expertise.
 
So, I propose we walk away from the current 
  implementation of general task as a constraint of task. Instead, create a new 
  general task specialization from base topic?
 
This would mean a new 
  top-level element name (<general-task>), a new body name 
  (<general-taskbody>), a new MOD file (general-task.mod), a new DTD shell 
  (general-task.dtd), etc.
 
This would resolve: 
  
    "Which task model to include in dita base" -- 
    Include *both* of them. 
    "Can we conref" -- Because they are clearly 
    different DTDs, the assumption will not be "yes, of course... they're the 
    same thing." 
    "Should we rename task.mod" -- Clearly 
    no.I think it's philosophically a 
  great idea to create task as a constraint of general task, but it's simply 
  causing more trouble for our basic users than it might be worth.
 
I know it's late in 
  the game, but the creation of this structural specialization would be simple 
  to do; it would affect only the terminology in a few papers by the Adoption TC 
  and the few articles that describe the "making of" general task. Ultimately, I 
  think it would require less effort for us, tool vendors, and the general user 
  population.
 
 
 
-seth park