[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Two suggestions for the DITA 1.0 Specification
Based on the excellent discussion that took place over the past few days, it seems that the DITA 1.0 Specification could benefit from two additional topics: A. Which base classes in topic.mod are conceptually the best "abstract" classes from which to specialize new elements of a given type? For example, given that we don't have an abstract class called <block element>, would someone attempting to specialize a new block element be best advised to specialize it from <p> or from something else? Or for when you need a titled block element, is <fig> the best choice? Some short list to this effect would be a boon to people approaching DITA for the first time. B. What are the ways in which you can more or less "safely" break DITA, and what are the consequences. Michael Priestley has talked about doing this in one form or another, and I think the spec is as good a place as any. Perhaps we could address basic techniques such as: * Making base class content models more restrictive in DTDs used for authoring, but using unmodified DITA DTDs for output processing. Benefit: Less complex doctypes for authors (by removing unnecessary choices) and ability to make existing content models more specific if desired. Your DITA instances are still 100% valid and interchangeable with 3rd parties, and assuming tools vendors do not validate CONREFed inclusions from 3rd party sources that use unmodified DITA, you can also safely CONREF 3rd party material into your more restrictive doctypes. Issues: More complex maintenance of your DTDs/Schema because you have to manage two sets: a modified set for authors and an unmodified set for output processing. * Adding new base classes or new base class attributes to your DTDs used for both authoring and output processing. The catch is that these added elements or attributes must be *optional* in every context in which they occur. Benefit: Nearly complete flexibility for your modeling/application/CMS needs. You can still safely CONREF 3rd party instances created with unmodified DITA into your doctypes, even if tools vendors actually validate CONREFed inclusions. You can still make use of DITA transforms in the public package and publically developed DITA transforms, requiring that you code only incremental specializations to transforms to deal with your new base elements/attributes. Issues: Your DITA instances will *not* valid DITA and will therefore will be unusable by 3rd parties. Interchange is one-way only, unless you create special transforms specifically for interchange processing that: strip your special attributes from instances, convert your added tags to some roughly equivalent tag in base DITA, and modify your DTDs/Schema handed out for interchange to specify different class paths for any elements that were specialized from your added base classes. It's nasty but it could be done. ------ There may be other ways to "safely" break DITA, but those are the two main ways that came to mind. For the folks that are hesitant to adopt DITA because they feel it doesn't meet their specific modeling requirements, I think a frank discussion of these "safe" practices in the 1.0 spec itself can go a long way towards helping them feel better about adopting DITA earlier rather than later. To that end, it might be also useful to discuss, in the same topic, the ways in which future releases of DITA might evolve to remove the need to perform these types of "safe" breakages. For example, we already know that we have to devise a mechanism to allow for specialization of attributes. We've also discussed the desirability of eventually adding new, more abstract base classes in order to help purists feel better about being able to create the models they need (ref: Eliot Kimber's strong aversion to specialing <fig> for an element that is not semantically a graphic of some sort). Can we stave off objections to limitations in the 1.0 release by including these two topics in the spec?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]