[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]