OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

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

  • 1.  Element Type Names Don't Matter--Class Is Everything

    Posted 08-04-2004 15:36
     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]