RE: [dita] DITA Task model

I agree completely with these statements. One of the primary focus’ of DITA is reuse and sharing. If we can’t share reusable content it negates the value of the standard. If we expect organizations to have an expert in XML to implement DITA we have lost them. One out of 10 of the organizations we work with might possibly have someone who understands XML, most do not.

This is only the tip of the iceberg. If we go towards enterprise use of DITA which could mean sharing of content between Tech Docs, Training, Marketing, Customer Support or more it will never become a realization if they cannot share.

We are in fact creating silos again. And at minimum, we are moving towards a situation where an organization has to constantly re-engineer their content if they want to adopt the latest standard and still continue to access their existing content.

I am equally concerned. It has also raised a lot of flags in the work we are doing in BusDocs.

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

dita message