OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

Namespaces and Schemas: Some Initial Findings and XSLT Implications

  • 1.  Namespaces and Schemas: Some Initial Findings and XSLT Implications

    Posted 06-28-2004 23:35
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    dita message

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


    Subject: Namespaces and Schemas: Some Initial Findings and XSLT Implications


    I spent the better part of the day experimenting with having schemas 
    that use a different namespace for each of the main top-level types 
    (that is, the types reflected by the .xsd files) taking advantage of the 
    technique whereby the .mod files need not declare a target namespace.
    
    Doing this satisfies my content management requirement that a given 
    namespace be governed by exactly one XSD document instance. For example, 
    I have the namespace "http://www.oasis-open.org/2004/DITA/base"; which 
    maps to the schema "http://www.oasis-open.org/2004/DITA/base ditabase.xsd".
    
    I doubt that this is actually a good approach--I think it's really the 
    case that DITA's top-level types (task, concept, reference, map, and 
    topic) all represent a single unified XML vocabulary that should be 
    declared as a single name space. I think that what is confusing the 
    issue is how the top-level schemas are currently organized. I suspect 
    that the right answer is that the DITA base schema (which includes all 
    the top-level types) is actually the only one required and that all 
    unspecialized DITA documents should refer to that schema. That would 
    also satisfy my requirement that there be exactly one schema for a given 
    namespace in my content management system.
    
    As far as XSLT processing goes...
    
    For this experiment I wanted to see what the implications would be on 
    the XSLT processing, because I knew it would complicated it but I wasn't 
    sure by how much.
    
    I started by modifying the existing topic2html.xsl to declare the base 
    namespace with a prefix ("dbase") and then added that prefix to all the 
    match= values on all the templates (which I was able to do pretty much 
    completely with a global search and replace).
    
    In my sample document I made the base namespace the root namespace 
    (meaning that I didn't have to modify any tags in the document except 
    for the document element). With a simple test style sheet I verified 
    that matches of the form match="dbase:p" would in fact match the correct 
    elements from the input document (mostly just to satisfy myself that I 
    had the XSLT namespace mechanism correctly set up).
    
    However, when I ran the ditaview_shell.xsl (which immediately delegates 
    to topic2html.xsl) I didn't get any output. Why not? One problem was 
    that there was no explicit template for the "dita" element. When I added 
    that, still nothing.
    
    The problem turned out to be that the topic2html.xsl style sheet is 
    written entirely against the class mappings, which is what it should do, 
    but because those class mappings are defined in the schema equivalent of 
    "fixed" attributes, Saxon doesn't see them because the open source 
    version of Saxon 8 isn't schema aware. Doh!
    
    This means, that from a practical standpoint, until more XSLT processors 
    are schema aware we must have some other way to provide the DITA mapping 
    attributes (and/or Schema-level class information) to XSLT processors. I 
    think this can be done through a SAX filter using a schema-aware 
    processor such as Xerces 2.6. I verified that with Xerces' DOM 
    implementation I could get access to the schema-supplied defaulted 
    attributes but when I passed that DOM to Saxon 7, Saxon didn't see them. 
    Not sure why, but it probably has to do with the way Saxon's DOMSource 
    class is implemented (the class that makes a DOM available to the XSLT 
    processor). If someone thinks this *should* work let me know.
    
    In my testing with Xerces it did not complain about the DITA schemas but 
    Saxon SA 8 did (both the base IBM DITA 1.3 schemas and my modified 
    versions), making it impossible to actually process the documents with 
    Saxon SA 8 (the commercial schema-aware version of Saxon). Doh!
    
    Note that this problem with defaulted attributes is a problem for anyone 
    doing schema-based XML processing with XSLT, not just a DITA problem. 
    It's just that DITA relies on the use of fixed attributes to a degree 
    that few other XML applications do. But for example all the technical 
    documentation DTDs I create depend on some sort of DITA-type class 
    mapping to one degree or another, largely so that processing such as 
    XSLTs can be simplified.
    
    Cheers,
    
    Eliot
    -- 
    W. Eliot Kimber
    Professional Services
    Innodata Isogen
    9030 Research Blvd, #410
    Austin, TX 78758
    (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]