[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Namespaces and Schemas: Some Initial Findings and XSLTImplications
Eliot Kimber wrote: >> Besides (can't help myself), that global search and replace is so... >> debasing. >> >> >>> Instances require only that the DITA namespace be declared as the root >>> namespace, which requires modifying only the root tag and no others, so >>> the impact on existing bodies of DITA documents is about as low as it >>> can be and still require some modification. > > > OK, pride goeth...I have realized that it's not quite so easy. I don't > see how it can be done with global search and replace, largely because > it would require matches of the "/." which matches too much stuff that > isn't XSLT expressions (such as URLs in namespace declarations). Doh! OK, I reworked the HTML generation style sheets (at least those used by ditaview_shell.xsl) to work with a single DITA namespace. This took me about 2 hours. Most of it was done with global changes but it did require some close inspection to find places where literal element type names had been used (which had to be replaced with proper class-based checks). I tested it lightly by creating a small document with a task, a reference, and a concept and including some more odd-ball elements like tables and syntax diagrams, just to make sure the basic code structure was correct and to test those places where I had found literal element type names. I also replaced the current "*[contains(@class, ' topic/title ')]" predicates with a call to an extension function that takes a node and a class name and returns true if the element is derived from that class. I did this mostly because this one check required all the @class attributes mentions to be qualified, whereas none of the others did (I'm not sure why but I verified that if I qualified any other attributes then they weren't matched or processed). Using a function also makes it easier to use a different class-specification mechanism without affecting the style sheets. I tested with Saxon 6.5 and Saxon 8. Unfortunately, Saxon 8 only supports XSLT 2.0 functions, not EXSLT functions, so I had to write two different versions of my function. I haven't tested with Xalan but if it supports EXSLT then the code should work. In any case it would be a reliable global change to replace the function call with the original direct predicate expression. Note that these generic, DITA-level style sheets have to be implemented *entirely* in terms of the class mapping and cannot use namespace qualification of element types at all, otherwise they wouldn't work for specialized documents, which would have to use a different namespace as their root namespace. But, by taking advantage of the fact that match="*" matches any element in any namespace you can write these sorts of name-space-independent style sheets. So I think I've demonstrated the following, at least to my satisfaction: - It's almost trivial to rework the existing schemas to be bound to a single namespace. The only wrinkle is that it makes the task, concept, and reference XSD files (as opposed to the .mod files) redundant and potentially confusing. That is, for a given namespace I think there should be exactly one XSD instance that names that namespace as its target namespace. In my experiments I've made that XSD document ditabase.xsd as it includes all the core DITA types. - The only modification required to existing DITA documents is to declare the namespace and point to the ditabase schema. Note that one could reasonably have a DITA-aware system that does the namespace-to-schema binding itself, so, strictly speaking, it is sufficient for documents to simply declare the DITA namespace. - It's not that much work to modify the existing XSLTs to make them schema aware. Now I can return to my original task, which was to implement a DITA-aware importer for XIRUSS-T (which requires that there be both a namespace and at most one top-level XSD for a given namespace). 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]