[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Element Type Names Don't Matter--Class Is Everything
The realization I had yesterday, which is not necessarily that deep or original, but that I think needs saying anyway, is that in DITA, or any similar architecture-based system, element type names are essentially irrelevant *for processing purposes*. Because DITA provides an explicit classification mechanism and because all generic DITA processing *must* be in terms of these classes and only in these terms and because all elements must be explicitly classified (by the rules of DITA), the element type name of any given element is completely irrelevant--the processor never even looks at it. The key here is the DITA requirement for universal explicit classification--because there is no default mapping of element types to architectural types, DITA processors *never* have to look at element type names. This is a key difference between DITA and the HyTime architecture mechanism (which provided for the default mapping of element types to architectural forms). Likewise, the processing of specialized elements can always be implemented in terms of their own specialized classes, not their element types. Of course, for authoring it's a different story--element type names are the main way that element types are exposed to authors. But we should all be able to agree that that is essentially an authoring user interface issue that could be addressed in other ways (for example, by having an editor reflect the class name instead of the element type name or using an alias as many editors allow you to do). [Of course I'm not saying that element type names *should* be arbitrary or obscure or opaque, just saying that element type name choice is a user interface design issue, not processing issue.] Given this realization, it should become clear that the namespace of the *element types* is essentially irrelevant for the purpose of defining and implementing DITA processing. That means that there is no particular need to put the DITA-defined element types into any particular name space. Likewise for specialized elements: for DITA processing purposes only their class values will be used so they could be in no name space or in any namespace--it simply doesn't matter. Thus as long as a processor can reliably distinguish DITA documents from non-DITA documents and as long as it can reliably find the DITA-specific class attribute, it can reliably apply DITA processing to those documents that contain DITA elements (and not attempt it for those elements that are not DITA elements) irrespective of the namespace qualifications of the element types. So, if you accept the fact that namespaces are the only way to 100% reliably bind markup constructs to their governing rules, then it follows that the only thing that *must* be namespaced is the DITA class attribute--it's the only thing processors care about and namespacing that one thing is sufficient identify a document as being a DITA document. And as I think of it now, this also suggests that the normative definition of the DITA document types should be a "data dictionary" of element classes, not a collection of element types or a DTD. That is, any DTD or schema that reflects the DITA *classes* is only one of an infinite number of possible such DTDs or schemas and therefore any DTD or schema published as a standard would not be *the* definition of the DITA types of merely a conforming implementation of the DITA types. We should certainly publish at least one DTD and one Schema as reference implementation but I don't think they can be *the* normative definition of what the DITA types are. NOTE: This is all completely orthogonal to issues of validation of documents and schemas--that can be done as it is now or done with DITA-specific document and schema validators. That problem is unchanged and current mechanisms are unaffected by qualifying just the class attribute (except for the trivial need to change code that finds class attributes to reflect the qualified name). Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9390 Research Blvd, #410 Austin, TX 78759 (512) 372-8122 eliot@innodata-isogen.com www.innodata-isogen.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]