One thing is abundantly clear to me -- We need to be very clear (and
accurate) in how we describe what has changed with DITA 1.2.
Both this discussion and the earlier thread about CTR underscore the
fact that there are a lot of people who are quite invested in DITA and
to whom a looser task model or a "base" that doesn't include CTR seems
(at least initially) utterly and completely alien. We need to keep this
audience in mind as we work on the specification (and packaging and
whatever) ...
Let's do our best to explain key changes thoughtfully, accurately, and
clearly.
Kris
Michael Priestley wrote:
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
http://dita.xml.org/blog/25
