OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] RE: Problems with the task model


JoAnn wrote:
If you look at the 1.2 lang spec, <task>, you’ll find this claim
 

“In the document types provided by OASIS with DITA 1.0 and 1.1, the task only allowed a single set of steps. In DITA 1.2 this restriction is relaxed so that a task may define more than one set of steps. However, OASIS will continue to distribute a sample document type that only allows a single set (using the new constraints mechanism available with DITA 1.2), for use by those that prefer the more restrictive model.” 
Looking back at the thread on this starting last February (MarkMail at http://tinyurl.com/mns8lh) I see no mention of defining more than one set of steps. The closest thing to that in the discussion there is the ability to have more than one level of substeps (sub-substeps, etc.).
 
The only way I see (maybe it is only the most obvious way) to have more than one set of steps is to have more than one <ol>. The ability to have more than one <ol> seems to me to be an undesirable side effect of the looser content model rather than a desideratum to be highlighted in the lang ref. Having more than one set of steps is a way of combining more than one task into a sequence or set of tasks. That should be done with <map>.
 
The earlier name for this steps-informal construct was process. I have always thought of a process as a sequence of tasks. Sometimes the best way to present this (in my experience) resembles a task or procedure, except that each step identifies the purpose or outcome of a task, with an appropriate reference or link to the task itself for detailed instructions. When this is constructed at a high level of generality it is sometimes called a roadmap, though that term is probably more often used for a set of pointers to entire documents.
 
In any case, this is semantically very different from steps-informal, and discussion of "more than one set of steps" in the language reference seems to me misguided (or misguiding), and is at variance to the discussion that I reviewed.

    /Bruce


From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Friday, September 11, 2009 10:18 AM
To: Steffen Frederiksen
Cc: dita@lists.oasis-open.org; Harold Trent; JoAnn Hackos
Subject: Re: [dita] RE: Problems with the task model


Hi Steffen,

The one task type is a clear subset of the other without new elements or semantics. It's exactly the problem that constraints were designed to address.

We already support having multiple interpretations of the same topic type - through domains. IE, you can have <task> with programming domain elements integrated, or without. Incorporating constraints is no different, and in fact uses the domains mechanism. We don't rename the root element every time we change the content model, either through constraints or through integrating domain elements.

I'll echo Erik's concern about Su-Laine's note - I can't see any technical reasons why constraints would be extra work to incorporate, other than the extra conref check (which is already custom code for DITA).

The change you propose specifically below would be too large to accomodate in 1.2, and also backwards incompatible - it would require everyone who wanted to continue using the strict task to rename elements in their documents (from <task> to <stricttask>)

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


From: Steffen Frederiksen <srf@dita-exchange.com>
To: JoAnn Hackos <joann.hackos@comtech-serv.com>, "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Cc: Harold Trent <harold.trent@comtech-serv.com>
Date: 09/11/2009 12:28 AM
Subject: [dita] RE: Problems with the task model





IMHO, your description of the problem JoAnn leads me to one and only one conclusion: We are actually talking about two content type:
1.       task (the new, less strict) – with a specialization:
2.       stricttask
 
It does NOT seem like the right solution – in DITA – to have and even try to support two “interpretations” of one content type.
 
Steffen
 
 
From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
Sent:
Thursday, September 10, 2009 23:56
To:
dita@lists.oasis-open.org
Cc:
Harold Trent
Subject:
[dita] Problems with the task model

 
I’ve spent the entire day trying to figure out what has happened to the task model since I’m trying to write the Technical Content section of the Arch Spec.
 If you look at the 1.2 lang spec, <task>, you’ll find this claim
 
“In the document types provided by OASIS with DITA 1.0 and 1.1, the task only allowed a single set of steps. In DITA 1.2 this restriction is relaxed so that a task may define more than one set of steps. However, OASIS will continue to distribute a sample document type that only allows a single set (using the new constraints mechanism available with DITA 1.2), for use by those that prefer the more restrictive model.”
 
The original strict task model is in OT 1.5. However, in PTC’s Arbortext 5.4, there is only the “generic” loose task model.
 
Also, I understand that Arbortext will not support the constraint mechanism with this release. Doesn’t seem to be in future plans either.
 
That means that companies that are using and want the strict task model are stuck. It’s not being made available. Are we going to see that with all the editor vendors because they don’t understand that there are now two task types?
 
 
Next,
I looked at the 1.2 lang spec, <taskbody> .
 
It shows the generic task model (loose) as contained in ditabase and the standard original better task model in “task”. Makes no sense of course
 

Then, to quote
 
“The <taskbody> element is the main body-level element inside a task topic. A task body is designed to contain information specific to completing a task, such as prerequisites, contextual information, and steps. With DITA 1.2, the content model of taskbody is looser to accommodate additional task structures. OASIS provides a DITA constraint that mimics the previous tight content model so that users continue to have easy access to the strict model.”
 
Another quote:
In the document types provided by OASIS with DITA 1.0 and 1.1, the task only allowed a single set of steps. In DITA 1.2 this restriction is relaxed so that a task may define more than one set of steps. However, OASIS will continue to distribute a sample document type that only allows a single set (using the new constraints mechanism available with DITA 1.2), for use by those that prefer the more restrictive model.
 
I don’t see anything in the lang ref, the dtd or the Arbortext 5.4 implementation any provision for additional sets of steps. Where is this supposed to happen?
 
How do we correct these issues?
 
JoAnn
 
JoAnn Hackos PhD
President
Comtech Services, Inc.
joann.hackos@comtech-serv.com
Skype joannhackos
 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]