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

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

Eric Sirois wrote:

> The Java app cheats the process a bit because it parses the document first
> and then passes the parsed document to the Transformation engine.  All the
> fixed attribute values
> have been resolved ahead of time.  Xalan assumes that it's simply an XML
> document that it needs to transform.  So you should be able to use the Java
> application with Saxon
> (regular version) and get the same results as Saxonica.

I have made this work with Saxon 8. It required the following:

1. set the Java system property -Djavax.xml.transform.TransformerFactory 
to "net.sf.saxon.TransformerFactoryImpl" to use Saxon instead of Xalan 
(which is built in to Java 1.4, which threw me for a minute). I tested 
with Saxon 8 (open source version) but it should work just as well with 
Saxon 6 as they both implement the JAXP APIs.

2. I had to refine one bit of code in Eric's TransformUsingXMLSchema 
class--when using Saxon (but not Xalan) I got a failure due to the 
output filename not being absolute. I changed the code to be:

if (htmlDoc != null){
     File htmlDocFile = new File(htmlDoc);
     t.transform(source, new StreamResult(htmlDocFile));
}

This means that the relevant schema awareness is provided entirely in 
the initial parsing and does not require any schema awareness in the 
XSLT engine itself.

I also realized that one must namespace qualify the attributes as well 
as the tag names in match statements, e.g.:

<xsl:template match="dbase:*[contains(@dbase:class,' topic/titlealts ')]"/>

So I am satisfied that moving to a schema-only approach would not 
prevent people from using common tools and the existing XSLTs with 
namespaces added.

Note that my modification of the existing XSLTs required only two global 
changes, one to add the prefix to element matches, one to add it to 
attribute matches, and a couple of post-change fixups where a couple of 
lines got qualified that should have. So from the standpoint of adapting 
the existing XSLTs to handle namespaced DITA documents, the cost is 
quite low. I haven't done all the XSLTs yet but if they follow the 
coding pattern used in topic2html.xsl it should be pretty easy (it helps 
that each template uses just one match term so I don't have to worry 
about matching matches that union several expressions).

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.

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