Folks,
The thread this morning on microXML, and specifically Don’s hope that it would include a content reference mechanism, has got me thinking about the structure of the DITA standard itself. XInclude isn’t part of core XML, it’s a separate standard built on top of XML. (The inclusion mechanism that is part of the standard - entities - is so fraught problems that the W3C felt it worthwhile to come up with something else.) This means that the availability of xinclude processing is not universal, but on the other hand you can understand and use XML without knowing anything about xinclude. The TC has spent a lot of time lately talking about complexity (perceived or actual, though I think it’s the latter), hurdles to adoption, and difficulties determining conformance. When we start talking seriously about DITA 2.0, I wonder if it would make sense to organize the standard using the modular approach used (on a much broader scale) by the various XML-related standards.
Rather than having a single omnibus spec, incorporating dozens of features and domains and document type shells, the DITA standard could be broken down into individual specifications, managed independently, comprising its various component features. There’d be a base DITA spec describing topic-oriented authoring and specialization technique, and specifying the base topic and map doctypes, but without any specializations or many of the features currently included in the spec (I’d argue that we should keep the list of “required” features in the base spec to a minimum). Then conref, keyref, mapref, ditaval, reltables, etc., as well as the various domain and structural specifications, could each be expressed in their own specifications.
A more modular set of specs would help with the complexity situation, since each individual specification could be kept relatively simple and self-contained. I think it would make adoption more straightforward and less intimidating. It would also help solve the issue of how to determine conformance, since each individual piece would have its own rules for establishing conformance. Thus vendors can remain “DITA compliant” while still picking and choosing the features they support.
There would be higher organizational overhead for the committee, but I don’t think anybody could argue that the current monolithic approach has led to a more efficient process, and the benefits might be worth the cost. (The OASIS bureaucratic requirements for such an approach might make it prohibitive, but that’s a different issue.) The flip side is that once all the ‘core specs’ are out there, we could introduce new DITA features without having to release a whole new version of the root spec.
There would also be a negative impact on interchangeability of content, since it might be authored with different tools supporting different subsets of DITA (I say conref, you say xinclude; I say profiling, you say ditaval; let’s call the whole thing off). But as we design new features for DITA, it’s a simple fact that not all tools are going to support all features.
These are just ruminations at this point, and I obviously haven’t thought through all the details and potential pitfalls, but I wanted to put it out there.
Chris
|
|
