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]