OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

Qualifying DITA Package and Class Names

  • 1.  Qualifying DITA Package and Class Names

    Posted 08-04-2004 20:47
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Qualifying DITA Package and Class Names


    In a separate thread, Erik Hennum said:
    
    > The realization that, for DITA processes, the class is
    > everything and the element name nothing is very
    > important.  My conclusion from this realization is that,
    > if we introduce namespaces, we need to use use
    > the namespaces in the class attribute as well.
    > 
    > Currently, we use a DITA-only identifier for each
    > specialization package.  These identifiers are at risk
    > for name collisions -- two specializers working
    > indepently could easily come up with the same
    > package identifier and only discover one another
    > years later after creating an immovable installed base.
    > The standard XML approach would be to use a
    > namespace for each specialization package
    > to prevent such collisions.
    
    I agree--within the universe of DITA package and class names, 
    non-DITA-defined names should be qualified as a matter of best practice.
    
    Functionally, DITA packages correspond exactly to namespaces in the XML 
    sense: they establish a unique name space of names that serve to 
    characterize XML elements, the names of DITA classes.
    
    This means that you could take the current DITA package name part of the 
    DITA class syntax "package/class" as the equivalent of a namespace 
    prefix and we could even consider changing the syntax to " 
    package:class" (that is, the value of the DITA class attribute would 
    become an ordered sequence of namespace-qualified names).
    
    [Aside: This observation supports Erik's assertion that each package 
    should have it's own namespace.]
    
    However, to anticipate Paul G's reaction (and probably Don's too), 
    making that kind of syntax change in 1.0 is probably not at all wise and 
    I *am not* suggesting it. Merely pointing out that it makes sense in the 
    abstract.
    
    However, it is still the case that there a real issue with how to 
    qualify package and class names in non-DITA-defined specializations.
    
    I think that in 1.0 we can solve this problem as follows:
    
    1. Assert that the "package/class" syntax is functionally equivalent to 
    "prefix:local_name" in that the package name is taken to be a namespace 
    prefix that maps to some defined namespace URI.
    
    2. Assert that in DITA 1.0 the DITA-defined package names are "magic" 
    reserved namespace prefixes and that documents do not need to delcare 
    these namespaces--conforming DITA processors will assume the 
    declarations of the corresponding namespaces URIs. We must define those 
    URIs in the 1.0 spec and it wouldn't hurt to include them in the DITA 
    schemas. But document instances would not need to declare them (that is 
    DTD-only or no-schema documents would still be fine).
    
    3. Assert that any non-DITA-defined package name must have a 
    corresponding in-scope xmlns declaration that maps that package name to 
    the appropriate namespace. Or, possibly, allow the package name to be 
    replaced by a URI (but I don't this would have to be allowed and 
    allowing it would introduce some potentially tricky syntax issues that 
    are probably better avoided in 1.0).
    
    4. Assert that DITA processors that can must expand package names to 
    their URIs for the purposes of mapping classes to processing or 
    validation rules (just as they would expand normal XML namespace 
    prefixes). Processors that cannot do that (i.e., non-DITA-aware CSS 
    renderers) just have to depend on the package prefixes being unique. 
    This means that if you are creating documents with two different 
    non-DITA-defined specializations, you better make sure that the local 
    package names are different so your CSS style sheets will work right.
    
    This approach provides the following:
    
    1. Does not require any syntactic change to any existing DITA documents 
    or schemas (because the current DITA-defined package and class names are 
    not changed).
    
    2. Does not break any existing DITA-base-aware processors (again, 
    because the DITA-defined class values haven't changed in any way).
    
    3. Provides for easy disambiguation of conflicting package names for 
    non-DITA-defined specializations.
    
    4. Uses exactly the same processing rules and expectations that 
    namespace-aware XML processing already imposes (that namespace prefixes 
    have to be expanded if you want 100% reliable processing but that if 
    you're pretty sure the prefixes are reliable without expansion you can 
    just use the prefix).
    
    5. Leaves the door open for alternative classification syntaxes in later 
    releases.
    
    6. Doesn't require any DITA-specific definitional mechanisms, such as a 
    DITA-specific "package namespace declaration".
    
    7. Does require that if you want to add the schema for a new 
    specialization to your schema and it comes with a prefix that conflicts 
    with one you already use in your schema, you will need to change one or 
    the other prefixes locally. I don't see a way to avoid this and keep the 
    existing class attribute syntax unchanged.
    
    In the post-1.0 timeframe I think we would probably want to think 
    seriously about providing a way to declare namespaces within class= 
    attribute values the same way you can in XPath 2 or in XPointer--this 
    would avoid the need to change DTDs and schemas locally just to 
    disambiguate two conflicting local prefixes.
    
    But otherwise I don't see any useful difference between DITA package and 
    class names and traditional XML namespaces and element type 
    names--they're just names in namespaces.
    
    Cheers,
    
    Eliot
    -- 
    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]