Re: [dita] Namespaces and Schemas: Some Initial Findings and XSLTImplications

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

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