xom-interest AT lists.ibiblio.org
Subject: XOM API for Processing XML with Java
List archive
[XOM-interest] XSLTransformer difficulties/questions
- From: Dirk Lattermann <dlatt AT alqualonde.de>
- To: xom-interest AT lists.ibiblio.org
- Subject: [XOM-interest] XSLTransformer difficulties/questions
- Date: Fri, 27 Mar 2009 21:45:00 +0100
(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] XSLTransformer difficulties/questions,
Dirk Lattermann, 03/27/2009
- Re: [XOM-interest] XSLTransformer difficulties/questions, Michael Kay, 03/27/2009
Archive powered by MHonArc 2.6.24.