XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

You could solve these problems very easily if you moved to using Saxon to
run your XSLT transformations, and Saxon APIs to control them. Saxon gives
you pretty good access to XOM trees as the input. To compile the stylesheet
(using Saxon's s9api interface), you would need to do something like this,
where stylesheet is the XOM Element node containing your stylesheet:

Processor processor = new Processor();
XsltCompiler compiler = processor.newXsltCompiler();

Document doc = stylesheet.getDocument();
DocumentWrapper docWrapper = new DocumentWrapper(doc);
NodeWrapper elementWrapper = docWrapper.wrap(stylesheet);

XsltExecutable exec = compiler.compile(elementWrapper);

That should give no problems with picking up all the inscope namespaces,
whatever level they are declared at. There's also no problem transforming an
input document supplied as a SAXSource.

(Not actually tested, though...)

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: xom-interest-bounces AT lists.ibiblio.org 
> [mailto:xom-interest-bounces AT lists.ibiblio.org] On Behalf Of 
> Dirk Lattermann
> Sent: 27 March 2009 20:45
> To: xom-interest AT lists.ibiblio.org
> Subject: [XOM-interest] XSLTransformer difficulties/questions
> 
> (I wasn't subscribed yesterday when I posted this and I 
> cannot see it yet in the archive, so I'm reposting. Sorry if 
> this appears twice.)
> 
> I have XSLT stylesheets embedded in an XOM Document. In my 
> application, I pick one and want to do a transformation. This 
> leads to several issues which I would like to discuss:
> 
> 1.
> 
> The stylesheet is available as a XOM Element and must be 
> passed to XSLTransformer. This can be done like so:
> 
>    new XSLTransformer(new Document((Element) stylesheet.copy()))
>    
> but seems like an unneeded and ugly copy to me (but see 2. below).
> 
> Inspecting the source of nu.xom.xslt.XOMSource, I guess it 
> would be simpler to add a constructor to XSLTransformer that 
> accepts Nodes instead of Document (easy since that argument 
> is just passed to the XOMSource). Then, one could say
> 
>    new XSLTransformer(new Nodes(stylesheet))
>    
> 
> 2.
> 
> I think this is tough: The above creation of an 
> XSLTransformer does not always work because the stylesheet 
> XOM Element does not contain all the needed namespace prefix 
> declarations. Namespaces that are declared on an enclosing 
> element are never added when no new Document is created from 
> the Element, and when a new Document is created, only those 
> namespaces are declared that are used in an actual element 
> prefix (and maybe attribute prefix, I didn't test). However, 
> they are sometimes needed when they appear as an element 
> prefix in attribute values (such as <xsl:apply-templates 
> select="pfx:elName"/>).
> 
> It is painful to add the prefix declarations to each of the 
> stylesheet elements instead of once in an enclosing element 
> (taking care not to use a prefix already used for the same 
> namespace in an enclosing element because in this case, the 
> declaration is not attached to the stylesheet element!!). But 
> maybe, this is still the most sensible approach to the whole problem.
> 
> It also seems expensive to me to use a deep copy of the 
> stylesheet just to obtain (in a new Document) some of the 
> needed namespace declarations of enclosing elements.
> 
> I read the apidocs for Element's addNamespaceDeclaration, but 
> using that method means to first find all effective namespace 
> declarations on an element. Is there no automatic way to 
> achieve the latter?
> 
> 3.
> 
> The data that must be transformed by the above stylesheets is 
> available as SAX events. As far as I can see, there is no way 
> to do this now with the XSLTransformer. I helped myself out 
> by adding a little method to XSLTransformer that creates a 
> TransformerHandler:
> 
> public TransformerHandler newTransformerHandler() throws 
> XSLException {
>     SAXTransformerFactory saxfactory = 
> (SAXTransformerFactory) TransformerFactory.newInstance();
>     try {
>         return saxfactory.newTransformerHandler(templates);
>     }
>     catch (TransformerConfigurationException ex) {
>         throw new XSLException("Could not create 
> TransformerHandler", ex);
>     }
> }
> 
> Would it be feasible to add that to the XOM API?
> 
> Greetings,
> Dirk
> 
> 
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest