[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]