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

[Michael Priestley <mpriestl@ca.ibm.com>]

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