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] constraints support? [Arbortext Editor] (Was: Problems with the task model)


Thanks Jeff for a very well-thought-out and worthwhile message.

 

>While no final decisions have been made, I think it is likely that we’ll make a general task template available, treat “task” as constrained task, and use the >proper names for “Task” and “General Task” in a future release.

 

That idea makes good sense to me. As a TC we really need to make sure that the DITA 1.2 documentation sets a convention for whether the word “task” without a qualifier means general task or constrained task. I vote for it to mean constrained task, because we are positioning DITA 1.2 as “adding the option to use a more relaxed task model” rather than “changing the model that everyone is used using for tasks.”

 

I’m *very* glad that JoAnn’s early adoption of DITA 1.2 has given us the chance to identify and fix these issues. I’ll try to respond to the questions on constraint support before Tuesday’s TC meeting.

 

Best regards,

Su-Laine

 

 

Su-Laine Yeo
Interaction Design Specialist

JustSystems Canada, Inc.
Office: 778-327-6356
syeo@justsystems.com

www.justsystems.com

 

 

 

 

From: Ogden, Jeff [mailto:jogden@ptc.com]
Sent: Friday, September 11, 2009 3:58 PM
To: dita
Subject: RE: [dita] constraints support? [Arbortext Editor] (Was: Problems with the task model)

 

This note explains what is going on within Arbortext Editor in terms of support for task and general task as well as for constraints.  I agree with the conclusions that seem to be being reached in the more general discussion of this topic on this list.

 

The 5.4 release of Arbortext Editor came out in late June 2009. It includes the preliminary version of the DITA 1.2 DTDs, XSDs, and related files from May 11, 2009.  Everything available from the DITA TC at that time is available, including the DTDs, XSDs, and related files for both task and general task.  

 

In one sense we didn’t implement “constraints” in the 5.4 release, but as Eliot has pointed out, in another sense we do support constraints because all that needs to be done is to support the DTDs or XML Schemas that include the constraints and we do that. What we don’t support is the additional checking for constraints that should be done for content references or some additional checking that could be done as part of our Enhanced DITA Completeness Checking or our DITA Specialization Validation code.  The lack of that checking doesn’t prevent anyone from doing anything, but it does mean that we don’t produce some error or warning messages for conrefs that we probably should. And while I don’t know exactly when we will be implementing these aspects of constraints, I do expect that we will be doing that work in the future.

 

While both task and general task are included in the Arbortext 5.4 release, we only make general task readily available via templates (our FileàNew dialog and the New Topic tab).  And if the 5.4 Editor is presented with a “task” document, it will be treated as a general task. Customers can reconfigure things to make General Task available via the UI and to treat tasks as constrained tasks if they wish.

 

We called the task template we do make available “Task” rather than “General Task”. Using that name may have been a mistake since it can lead to confusion.  

 

In part the reason we only made one task type readily available was that we knew we were including preliminary DITA 1.2 DTDs and XSDs before they were officially approved by OASIS and we wanted to keep things looking as much like they did in DITA 1.1 as we could. Looking back now I’m not sure we did that in the best way or that it was even the right decision.

 

Another reason we choose to make just one type of task readily available “out of the box” is that we have an internal mechanism that is subject to the same limitation that Eliot described for ditabase, that a given doctype shell can support either task or general task, but not both.  We chose to support general task for the same reason that I suspect that the DITA TC included general task rather than task in ditabase, that general task is a superset of task and so task will be legal within a ditabase or within our internal mechanisms. If we had included task rather than general task, general tasks would have been flagged as invalid. 

 

While no final decisions have been made, I think it is likely that we’ll make a general task template available, treat “task” as constrained task, and use the proper names for “Task” and “General Task” in a future release. We would continue to use general task as part of our ditabase and within our internal mechanisms since that allows us to support both task and general task.

 

It might be the case that we’ll choose to make task readily available as a constrained task, but keep general task somewhat more hidden, but available for use as a base for specializations. If we do take that approach, it would still be fairly easy for customers to reconfigure things to make general task more visible if they wish.

 

Hope this helps clarify things.  Sorry for the length of the message.

 

    -Jeff

 

From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
Sent: Thursday, September 10, 2009 5:56 PM
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

 

cid:image001.gif@01CA3242.771510A0

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

 

cid:image002.jpg@01CA3242.771510A0

 

cid:image003.jpg@01CA3242.771510A0

 



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