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:]
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
