MHonArc v2.5.0b2 -->
dita message
[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]