RE: [dita] task vs. general task, constraints, conref, and other related

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

dita message