RE: [dita] DITA Task model [and PTC's Arbortext Editor]

["Ogden, Jeff" <jogden@ptc.com>]

Title: DITA Task model

Joann wrote in part:

The Arbortext decision to call general task “task” has revealed this problem, which was actually quite fortuitous. Considering their decision, was anyone from PTC aware of the problems that were going to occur if adopters begin using more than one task model. The situation in Arbortext Editor 5.4 is untenable, at least for all of my community. As I understand it, if authors use task quite innocently in 5.4 Out of the Box, they will invalidate all their conrefs already developed in DITA 1.1. That’s a truly critical problem.

 

We (PTC) understood some, but not all of the implications of moving to two task models (strict and general). For example I missed the conref limitation.

 

Using the name “Task” for “General Task” was a mistake, which we (PTC) need to correct.

 

Including “General Task” rather than strict “Task” in ditabase was a mistake that the DITA TC seems poised to correct and which I expect we (PTC) will install once the DITA TC’s decision is finalized.

 

How many ditabases to include in DITA 1.2 is still an open question and I’m not sure that the TC is zeroing in on an answer.  My own vote is to include just one and that should include the strict version of task.

 

There are questions about the exact timing of any changes to be made at PTC that remain to be worked out. It would be helpful if the TC could settle on its solution to this issue since it is hard to make plans for the future when the ground rules might still change.

 

If someone works with tasks entirely within Arbortext Editor, they won’t run into any problems with Tasks or General Tasks.  But if someone exchanges Tasks with others that aren’t using Arbortext Editor, that might result in an invalid document at the non-Arbortext site. If there is a problem, it can be worked around fairly easily, but at the cost of having to use the less strict rules which may not be something that someone wants to do or editing your tasks so they follow the strict rules which may also be something that folks don’t want to do.  It is this potential problem that is driving me to think that we (PTC) need to make changes sooner rather than later.

 

A larger question that all of this raises for me is if the decision to include the preliminary versions of the DITA 1.2 DTDs and XSDs in the Arbortext 5.4 release before DITA 1.2 was more formally approved was a mistake.  I’ve got very mixed feelings about that at this point.  Of course we expected DITA 1.2 to be an approved OASIS Standard by now.  And a decision to not include DITA 1.2 when we did might have resulted in a delay of from 18 to 24 months, which at the time didn’t seem acceptable.  And the drive to include DITA 1.2 when we did, did have some advantages since it uncovered and allowed a number of problems with the DTDs and XSDs to be fixed earlier than would otherwise have been the case.  We just didn’t find or understand everything. But you almost never do.

 

   -Jeff

 

From: Joann Hackos [mailto:joann.hackos@comtech-serv.com]
Sent: Thursday, September 24, 2009 9:38 AM
To: DITA TC
Subject: [dita] DITA Task model

 

When was it decided that the original task model in DITA 1.1 would be rewritten as a constraint of the general task model? I don’t recall hearing any discussion of the impacts of such a rewrite. Instead of being a specialization of topic, task is now a constraint of general task. Why was this decision made and did anyone consider the implications of the change from a specialization to a constraint?

What is the full impact of the decision by someone by rewrite task? Is task in DITA 1.2 full compatible with task in DITA 1.1? Will conrefs written in DITA 1.1 task function properly in DITA 1.2 task? I really would like an answer to the constraint decisions.

Machinery task is also written as a constraint of the DITA 1.2 general task. Is it also incompatible with either general or strict task?

It appears that this means that an organization in which content is shared among tasks must be extremely careful that only one task model is used. Is that a correct assumption? Is DITA 1.2 task backward compatible with DITA 1.1 task?

I don’t think we can take this at all lightly. Despite Eliot’s argument that you have to be an XML expert programmer to implement DITA, that is not the reality in the user community. How will we possibly communicate the enormous problems that will result if conrefs no longer work? As the co-chair of the Adoption TC, I don’t even know where to begin.

The Arbortext decision to call general task “task” has revealed this problem, which was actually quite fortuitous. Considering their decision, was anyone from PTC aware of the problems that were going to occur if adopters begin using more than one task model. The situation in Arbortext Editor 5.4 is untenable, at least for all of my community. As I understand it, if authors use task quite innocently in 5.4 Out of the Box, they will invalidate all their conrefs already developed in DITA 1.1. That’s a truly critical problem.

To repeat, conrefs do not work between general task and task. Do they work between task 1.1 (specialization) and task 1.2 (constraint)? Or between machinery task and other tasks?

I lost sleep last night stewing over this. It may cause more problems among adopters than we will be able to handle.

JoAnn