[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] constraints support? [Arbortext Editor] (Was: Problems with the task model)
This
note explains what is going on within Arbortext Editor in terms of support for
task and general task as well as for constraints. I agree with the conclusions
that seem to be being reached in the more general discussion of this topic on
this list. The
5.4 release of Arbortext Editor came out in late June 2009. It includes the
preliminary version of the DITA 1.2 DTDs, XSDs, and related files from May 11,
2009. Everything available from the DITA TC at that time is available,
including the DTDs, XSDs, and related files for both task and general task.
In
one sense we didn’t implement “constraints” in the 5.4
release, but as Eliot has pointed out, in another sense we do support
constraints because all that needs to be done is to support the DTDs or XML
Schemas that include the constraints and we do that. What we don’t
support is the additional checking for constraints that should be done for
content references or some additional checking that could be done as part of
our Enhanced DITA Completeness Checking or our DITA Specialization Validation
code. The lack of that checking doesn’t prevent anyone from doing
anything, but it does mean that we don’t produce some error or warning
messages for conrefs that we probably should. And while I don’t know
exactly when we will be implementing these aspects of constraints, I do expect
that we will be doing that work in the future. While
both task and general task are included in the Arbortext 5.4 release, we only
make general task readily available via templates (our FileàNew dialog and the New Topic tab).
And if the 5.4 Editor is presented with a “task” document, it will
be treated as a general task. Customers can reconfigure things to make General
Task available via the UI and to treat tasks as constrained tasks if they wish.
We
called the task template we do make available “Task” rather than
“General Task”. Using that name may have been a mistake since it can
lead to confusion. In
part the reason we only made one task type readily available was that we knew
we were including preliminary DITA 1.2 DTDs and XSDs before they were
officially approved by OASIS and we wanted to keep things looking as much like
they did in DITA 1.1 as we could. Looking back now I’m not sure we did
that in the best way or that it was even the right decision. Another
reason we choose to make just one type of task readily available “out of
the box” is that we have an internal mechanism that is subject to the
same limitation that Eliot described for ditabase, that a given doctype shell
can support either task or general task, but not both. We chose to
support general task for the same reason that I suspect that the DITA TC
included general task rather than task in ditabase, that general task is a
superset of task and so task will be legal within a ditabase or within our
internal mechanisms. If we had included task rather than general task, general
tasks would have been flagged as invalid. While
no final decisions have been made, I think it is likely that we’ll make a
general task template available, treat “task” as constrained task,
and use the proper names for “Task” and “General Task”
in a future release. We would continue to use general task as part of our
ditabase and within our internal mechanisms since that allows us to support
both task and general task. It
might be the case that we’ll choose to make task readily available as a
constrained task, but keep general task somewhat more hidden, but available for
use as a base for specializations. If we do take that approach, it would still
be fairly easy for customers to reconfigure things to make general task more
visible if they wish. Hope
this helps clarify things. Sorry for the length of the message.
-Jeff From: JoAnn Hackos
[mailto:joann.hackos@comtech-serv.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]