[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] task vs. general task, constraints, conref, and other related issues
Here is
the updated summary of the issues related to task vs. general task,
constraints, conref, and other related issues that I agreed to send following
today's DITA TC meeting. It is just a reordered and updated version of the
message I sent before the DITA TC meeting. Robert
wrote an FAQ about constraints that everyone who is interested in this topic
should read: http://wiki.oasis-open.org/dita/ConstraintsFaq
Here are
the open questions. Only items 1, 2, 3, and 4 were discussed during today’s TC
call. Item 4 was only discussed very briefly. 1. Questions have been raised about the
constraints mechanism in general and if it was appropriate to use it to
implement the new versions of task that are part of DITA 1.2. At the TC
meeting Joann made a proposal to abandon the current approach of using
constraints to implement general and strict task in DITA 1.2. As an
alternative she suggested two peer task specializations both based on topic. Others
suggested that implementing strict task as a specialization of general task without
using constraints as another approach. After a good deal of discussion, it was
decided that we should stick with the current approach of using constraints to
implement strict task based upon general task. 2. It has been stated that within a
single organization or within a single authoring group, that in general only
one version of an information type SHOULD be used within a group and that we
should explain why that is the case and recommend that approach somewhere in
the DITA 1.2 specification as well as in a best practices document that might
be written by the DITA Adoption TC. There were a number of questions about
exactly what should be said and where it should be said, but there seems to be
agreement that something should be said somewhere. 3. There was a question about the wisdom
of including both task.dtd (strict task) and generalTask.dtd in the DITA 1.2
specification. No final decision was made, but the TC seemed to be leaning in
the direction of including both with appropriate warnings and recommendations in
the specification and a best practice. 4. There is a preliminary proposal to
allow “weak” constraints to be declared. So far no one has raised technical
complaints about the proposal. There has been support for including the
proposal as part of DITA 1.2 expressed by several people. There have been
reservations about considering the proposal this late in the DITA 1.2 cycle. I
expressed a reservation about this making things more complicated with the
possibility of yet more combinations of things. There is a concern that
MP and others may not have the necessary bandwidth in the short run to turn
this into a more formal and complete proposal. MP said he would think about his
time over the coming week, but that he didn’t think this would be a huge effort
and that he could probably accommodate it. Others stated that there were
constraints on their own time (they didn’t say if those constraints were strong
or weak). If the weak constraints proposal does go forward, the TC will need to
make some decisions about using “week” or “strict” constraints for task.dtd and
ditabase.dtd 5. An alternative that was not discussed
would be to make all constraints “weak” as far as conref validation is
concerned in DITA 1.2 without the need to declare them as such. Given the
current state of many conref validation implementations, this is pretty much
the de facto state of affairs today. If “weak” constraints were the norm for
DITA 1.2, “strong” constraints could be added in DITA 1.3 using s(…). 6. There have been a lot of discussions
about what is and isn’t or what should and shouldn’t be valid when using
conref. There is one question about doing conref validation based on content
models in DTDs or XSDs rather than information in the domains attribute
value. Several people pointed out why DITA doesn’t use the actual content
models in the DTDs or XSDs for conref validation and instead uses values from
the domains attribute. I’m not sure there is still an open question related to
this. I’m not aware of any other specific open questions or decisions for DITA
1.2 coming out of this portion of the discussion. 7. The TC has decided that strict task
rather than general task should be included in the ditabase doctype shell that
is included as part of Technical Content. DTDs, XSDs, and the DITA 1.2
specification will all need to be updated. 8. There is an open question about the
need to include a second ditabase doctype shell that would include general task
rather than strict task. The TC seemed to be leaning toward not including
a second ditabase doctype shell, but I don’t think there is a consensus about
that and a final decision remains to be made. If a decision is made to
include a second ditabase, we would need to pick a location for the additional
doctype shell, filenames, a Public ID, and a URI, and the DTDs, XSDs, and the
DITA specification would all need to e updated. 9. The names we have for task.dtd,
generalTask.dtd, task.mod, task.ent, strictTaskbodyConstraint.mod and the
associated XSDs, Public IDs, and URIs seem confusing. Would new names for
some of the these items help? task.dtd might become strictTask.dtd,
task.mod à genTask.mod, task.ent à
gentask.ent. For compatibility with DITA 1.1 and 1.0 we’d probably need to use
the same sort of trick we used with glossary and glossentry, so the old names
would continue to work. 10. Many of the issues we’ve been
discussing seem to arise from shortcomings of ditabases and shortcomings of
DTDs --that a ditabase can only contain a single use (constrained or
unconstrained) of a particular info type. Should we look for ways to
remove or relax that restriction in DITA 1.3 or 2.0? 11. Eliot added some questions about topic
nesting, conref validation, and the domains attribute to the list of things to
consider for DITA 1.3. If I’ve
left anything out or there are other questions that need to be discussed and decided,
please add them to the list. -Jeff |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]