Namespaces and Schemas: Some Initial Findings and XSLT Implications

[Eliot Kimber <ekimber@innodata-isogen.com>]

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