Element Type Names Don't Matter--Class Is Everything

[Eliot Kimber <ekimber@innodata-isogen.com>]

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