> So it seems to mean a new XSLT 2.0 processor has been released about > two weeks ago? > > http://www.ibm.com/common/ssi/rep_ca/1/897/ENUS209-391/ENUS209-391.PDF Yes, though it's only available as part of the Websphere environment. (Don't bother asking me whether it will be available through other channels. I honestly don't know, and if I did I couldn't say so anyway.) ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
keshlam@us.ibm.com schrieb am 01.12.2009 um 09:13:46 (-0500): > > It means I've been involved with IBM's new XML Feature Pack for > Websphere, which supports the 2.0 versions; hence my carelessly > suggesting a 2.0-only solution. So it seems to mean a new XSLT 2.0 processor has been released about two weeks ago? http://www.ibm.com/common/ssi/rep_ca/1/897/ENUS209-391/ENUS209-391.PDF -- Michael Ludwig
The xmlns attribute sets the default namespace. XSLT is namespace-sensitive; to match namespace-qualified elements and attributes you must match the namespaces as well (which means using prefixes in your XSLT even though you used the default in the instance document, since XSLT 1.0 has no ability to specify a default namespace for its match/select patterns). ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
> Does that mean Xalan's going 2.0? It means I've been involved with IBM's new XML Feature Pack for Websphere, which supports the 2.0 versions; hence my carelessly suggesting a 2.0-only solution.
Hi all, I'm having some problems using Xalan to make XSLT using JAXP Java API. When xmlns attribute is not present in root element of the input xml, the output is fine. When xmlns is present, Xalan is generating an empty output. Is there any issue regarding this? I've been searching all over the documentation and I could not find anything. Thanks in advance, Gustavo Honorato
keshlam@us.ibm.com schrieb am 30.11.2009 um 11:46:31 (-0500): > > Pretty sure XPath 1.0 [1] only allows foo:* wildcards (but not > > *:foo). > > ... Right. Sorry; too much time working on 2.0 recently. Does that mean Xalan's going 2.0? -- Michael Ludwig
Marc Ende schrieb am 01.12.2009 um 14:38:39 (+0100): > Hi Michael, > > thanks for your help. It seems that the issue doesn't relate to the > '.'. But I have no further ideas. Can you have a look on this > stylesheet and the input xml. I thought that the issue that the > xsd:value-of doesn't provide any data relates to the dots. But now I > know that's not the case. > > Maybe you can give me a hint. I've spend about 8 hours and haven't > found any point how I can resolve this issue. Marc, please reply to the list, not privately. (I know you did it inadvertently, as this list does not set the Reply-To header as it should.) As to the issue at hand, it is dead simple. Your input is in a namespace, and your stylesheet doesn't take that into account. Read up about XML namespaces to save you from further harm and waste of time. XML namespaces are trivial to understand, but a bit annoying due to excessive URI verbosity. <xmeldit.datenlieferung.1100 fassung="2009-07-31" version="1.5" produkt="OK.EWO" produkthersteller="AKDB" produktversion="05.70.10" xmlns="http://www.osci.de/xmeld15" xmlns:xoev="www.deutschland-online.de/XOEV" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.osci.de/xmeld15 S:\e01entw_eGov\XMELD\XMELD1~1.5\xmeld-nachrichten-xmeldit.xsd"> [...] The URI for xoev does not look like a valid URI. <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> [...] Your stylesheet should declare all namespaces that are needed and use them accordingly. <xsl:transform version="1.0" xmlns="http://www.osci.de/xmeld15" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> Plus, you *absolutely* need to learn about "push" vs "pull" approach. You're using the pull approach, which is only suitable for the most trivial tasks. The one you have looks like a job for a push approach. The "modified identity template" approach I mentioned is a push approach. Good luck, -- Michael Ludwig
Marc Ende schrieb am 01.12.2009 um 10:39:20 (+0100): > But within the source-xml they've got '.' in the tags. For example: > > <root.element> > <test.element>Hello World</test.element> > </root.element> There's nothing unusual at all with that. > If I try to access the value with such xslt I got nothing: > > <xsl:template match="/"> > <test><xsl:value-of select="root.element/test.element"/></test> > </xsl:template> Works fine for me. Did you apply the stylesheet to the correct input? > I tried to escape the dots in the select with '\.' but that doesn't > work. It doesn't because you must not prefix the dot with a backslash. XPath does not follow the same rules as grep, or the shell, or Perl. > In XPath there was the . mentioned as a replacement for a character. > So it should also work on '.' I think. Don't know what you mean, but "." is the current context node. > By the way. Is there any way to 'copy' parts of one xml in the other > xml within the transformation? > It would be helpful if there are parts which doesn't need to > transformed (just copied). I think you're looking for the standard pattern called "modified identity transform". Googling for that will teach you the concept. It's not difficult and really practical. Best, -- Michael Ludwig
Hi, since yesterday I've got a project on xslt transformation from one xml to another schema. But within the source-xml they've got '.' in the tags. For example: <root.element> <test.element>Hello World</test.element> </root.element> If I try to access the value with such xslt I got nothing: <xsl:template match="/"> <test><xsl:value-of select="root.element/test.element"/></test> </xsl:template> It I try it without dot's: <root> <test>Hello World</test> </root> and <xsl:template match="/"> <test><xsl:value-of select="root/test"/></test> </xsl:template> Everything works fine. I tried to escape the dots in the select with '\.' but that doesn't work. In XPath there was the . mentioned as a replacement for a character. So it should also work on '.' I think. Does anybody has an idea? By the way. Is there any way to 'copy' parts of one xml in the other xml within the transformation? It would be helpful if there are parts which doesn't need to transformed (just copied). Thanks for your help! Marc
> Pretty sure XPath 1.0 [1] only allows foo:* wildcards (but not *:foo).
... Right. Sorry; too much time working on 2.0 recently.
The 1.0 equivalent would indeed be
*[localname()="foo"]
And, of course, if you want to ignore the name entirely, just matching on
* will do that.
NOTE: Since the namespace is part of the semantics (meaning) of the
document, ignoring it is usually an indicator of bad design (unless you're
working in 2.0 and manipulating schema types rather than names). Think
long and hard about what you're really trying to do and whether this is
the best way to do it.
Content-type: text/plain; charset=US-ASCII keshlam@us.ibm.com wrote on 11/30/2009 11:28:36 AM: > > As we have xs:any in xerces for any namespace usage , how do I > > achieve in xslt ? I could not find any construct in xsl as we have > > in schema language. > > XSLT 1.0 and XPath 1.0 are not schema-aware. (That was added in the > 2.0 version of these, which Xalan does not yet support.) > > If you want to match names without looking at the namespace, you can > use wildcard QNames such as *:foo, or match on a wildcard and then > qualify that with a predicate. I believe that form [1] has only been supported since XPath 2.0. Pretty sure XPath 1.0 [1] only allows foo:* wildcards (but not *:foo). Thanks. [1] http://www.w3.org/TR/xpath20/#prod-xpath-NameTest [2] http://www.w3.org/TR/xpath#NT-NameTest Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org
> As we have xs:any in xerces for any namespace usage , how do I > achieve in xslt ? I could not find any construct in xsl as we have > in schema language. XSLT 1.0 and XPath 1.0 are not schema-aware. (That was added in the 2.0 version of these, which Xalan does not yet support.) If you want to match names without looking at the namespace, you can use wildcard QNames such as *:foo, or match on a wildcard and then qualify that with a predicate.
Hi all,
As we have xs:any in xerces for any namespace usage , how do I achieve in xslt ? I could not
find any construct in xsl as we have in schema language.
Could you please tell me, is there any way we can achieve the same thing like xs:any ??
Regards
Ajay
Nathan Nadeau schrieb am 23.11.2009 um 18:12:01 (-0500): > The source of the problem is that FOP is mistakenly calculating the > base-URI for the images. The purpose of xml:base is to rectify > situations like this, but it seems that FOP does not know what to do > with xml:base. For you, it's reporting xml:base as an invalid > attribute of the fo:block element. For me, it just ignores xml:base > and continues (of course still incorrectly resolving the image URIs). > > First thing I would verify is that your XSLT and/or XSL-FO files are > aware of the "xml" namespace. I tried this first on my setup, but it > did not help. Maybe it will help you? Can't help with FOP, but as for the "xml" namespace, it does not need to be declared as it is by default. http://www.w3.org/TR/xml-names/#ns-decl Namespace constraint: Reserved Prefixes and Namespace Names The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. Note that the notion of *files* being "aware" of the "xml" namespace is misleading. A *parser* implementing namespaces is required to have a binding for "xml" to the appropriate namespace. Next, there needs to be support for xml:base. XSLT 1.0, which was published in 1999 [1], does not mention xml:base, which was published two years later [2]. However, there is support for base URIs. Support for enhanced base URIs as per the 2001 xml:base add-on is up to the implementation: * Saxon 6.5 - yes * LibXSLT 1.1.24 - yes * Xalan-J 2.7.1 - no Last, in XSLT/XPath 2.0 you can access the base URI directly using the base-uri() function [3]. [1] http://www.w3.org/TR/xslt#base-uri [2] http://www.w3.org/TR/xmlbase/ [3] http://www.w3.org/TR/xpath-functions/#func-base-uri -- Michael Ludwig
The source of the problem is that FOP is mistakenly calculating the
base-URI for the images. The purpose of xml:base is to rectify
situations like this, but it seems that FOP does not know what to do
with xml:base. For you, it's reporting xml:base as an invalid attribute
of the fo:block element. For me, it just ignores xml:base and continues
(of course still incorrectly resolving the image URIs).
First thing I would verify is that your XSLT and/or XSL-FO files are
aware of the "xml" namespace. I tried this first on my setup, but it did
not help. Maybe it will help you?
If that doesn't work, there are certainly ways to work around the problem:
1) Download the images to a corresponding local directory in a
pre-processing step. Or you could program a Xalan extension that
basically does the same thing "inline" in the XSLT.
2) Explicitly compute the base URI for the particular HTML document
you're processing and use that value to create an absolute URI in
<fo:external-graphic>. Something like "concat($base-URI,@src)". You
could either pass in $base-URI as a global XSLT parameter (if you know
this beforehand), or you can calculate it dynamically for each document
you process by finding the directory of the a/@href attribute (the
portion of the URI leading up to the file, but not the file name
itself). Then you'd send that value along to the matching templates with
<xsl:apply-templates><xsl:with-param name="base-URI" select="blah"/>,
and you'd need to make sure your matching templates include that
parameter with <xsl:param name="base-URI"/>. Then, when you're
outputting the external graphic, you'd do something like
<fo:external-graphic src="url('{concat($base-URI,@src)}')"/>.
3) Tell FOP to use a given base-URI via the configuration file. See
http://xmlgraphics.apache.org/fop/0.94/configuration.html. It seems you
can only do this if you already know the base-URI value beforehand, and
you can only have one value per FOP run. I actually used this option
with your example files and it worked for me. No change was needed to
your files, and I didn't need to use xml:base, but of course you need to
know the base-URI beforehand, or otherwise somehow loop through calls to
FOP, updating the config file appropriately on each call.
Cheers,
Nathan Nadeau
Jack Bates wrote:
> I originally posted this question to the FOP users list,
> http://thread.gmane.org/gmane.text.xml.fop.user/29778
>
> I'm writing a stylesheet that includes this template,
>
> <xsl:template match="html:img">
> <fo:external-graphic src="url('{@src}')"/>
> </xsl:template>
>
> - but when I process it I get errors like,
>
> $ fop -xml index.html -xsl index.xsl index.pdf
> [...]
> 16-Nov-2009 11:06:32 AM org.apache.fop.events.LoggingEventListener processEvent
> SEVERE: Image not found. URI: /docs/images/thumb/b/bb/UM-2.1.png/500px-UM-2.1.png. (No
context info available)
> [...]
>
> - and the generated PDF is missing some images : (
>
> I think the problem is that the stylesheet uses the document() function
> to get HTML pages from the web,
>
> <xsl:template match="html:a" mode="foo">
> <fo:block>
> <xsl:apply-templates select="document(@href)//html:body"/>
> </fo:block>
> </xsl:template>
>
> - and these pages, e.g. http://ica-atom.org/docs/index.php?title=UM-2.1
>
> - have some relative images,
> e.g. /docs/images/thumb/b/bb/UM-2.1.png/500px-UM-2.1.png
>
> The <img> elements are part of the HTML document, and so relative to
> http://ica-atom.org/docs/index.php?title=UM-2.1, but I guess the
> <external-graphic> elements aren't?
>
> I tried adding an xml:base="" attribute,
>
> <xsl:template match="html:a" mode="foo">
> <fo:block xml:base="{@href}">
> <xsl:apply-templates select="document(@href)//html:body"/>
> </fo:block>
> </xsl:template>
>
> Here's a simplified, complete example,
>
> http://www.sfu.ca/~jdbates/tmp/fop/200911160/index.html
>
> http://www.sfu.ca/~jdbates/tmp/fop/200911160/index.xsl
>
> - but now when I process this example I get this error,
>
> $ fop -xml index.html -xsl index.xsl index.pdf
> 16-Nov-2009 11:29:57 AM org.apache.fop.cli.Main startFOP
> SEVERE: Exception
> javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: Invalid
property encountered on "fo:block": xml:base (No context info available)
> at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:314)
> at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:146)
> at org.apache.fop.cli.Main.startFOP(Main.java:174)
> at org.apache.fop.cli.Main.main(Main.java:205)
> [...]
>
> How can I automatically convert these HTML pages to a PDF with XSL-FO?
>
Content-type: text/plain; charset=US-ASCII
Right, that's exactly how it works:
public LSSerializer createLSSerializer() {
try {
Class serializerClass = ObjectFactory.findProviderClass(
"org.apache.xml.serializer.dom3.LSSerializerImpl",
ObjectFactory.findClassLoader(), true);
return (LSSerializer) serializerClass.newInstance();
}
catch (Exception e) {}
// Fall back to Xerces' deprecated serializer if
// the Xalan based serializer is unavailable.
return new DOMSerializerImpl();
}
Was hoping to put a warning in there if it takes the fallback path but
there's no DOMErrorHandler to report it to at this point.
FYI: If you don't have Xerces on the classpath but instead try to access
the JDK version [1] you may not get very far.
Thanks.
[1] http://markmail.org/message/e6rlhwymr43p4u4v
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Dick Deneer <dick.deneer@donkeydevelopment.com> wrote on 11/22/2009
04:06:06 PM:
> Hi Benson,
>
> As Michael notes, Xerces is now shipped with the serializer.jar
> (which contains the xalan serializer). If you have this on your
> classpath it will be used.
> If you leave it out, then xerces will fall back to it's own (deprecated)
one.
>
> regards
> Dick Deneer
> Op 22-nov-2009, om 21:54 heeft Benson Margulies het volgende geschreven:
>
> Hi Michael,
>
> So, if I put Xerces and not Xalan into classpath, and ask a document
> for it's implementation, and ask that for the DOMImplementationLS,
> what do I get? Whatever Sun tossed into the pot? And if I then add
> Xalan, do I get the right one?
>
> --benson
>
> On Sat, Nov 21, 2009 at 10:24 PM, Michael Glavassevich
<mrglavas@ca.ibm.com
> > wrote:
> Hi Benson,
>
> We're talking about two different implementations of the DOM Level 3
> LSSerializer, the more recently developed one in Xalan
> (serializer.jar which Xerces now ships and shares with Xalan) and
> the much older deprecated one in Xerces. If you're curious about the
> history on that, there's an FAQ [1] on the website.
>
> Some users have decided to keep using Xerces' deprecated serializer
> due to some quirks and issues with the currently available one from
> Xalan. Folks really should be opening JIRA issues [2] against Xalan,
> so those problems get addressed there. There's no intention to do
> any further development or fixes to the one in Xerces.
>
> Thanks.
>
> [1] http://xerces.apache.org/xerces2-j/faq-general.html#faq-6
> [2] https://issues.apache.org/jira/browse/XALANJ
>
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
> Benson Margulies <bimargulies@gmail.com> wrote on 11/21/2009 02:17:49 PM:
>
>
> > Could I please ask for a bit of clarification? The only LSSerializer
> > I'm aware of is the DOM level 3 stuff, which, I thought, was the
> > opposite of obsolete. As someone pointed out here, unlike TraX, it
> > will serialize doctypes and do other handy things. In general, I'm
> > beginning to prefer the DOMImplementationLS to JAXP and TraX.
>
> > On Sat, Nov 21, 2009 at 2:07 PM, Michael Glavassevich
<mrglavas@ca.ibm.com
> > > wrote:
> > You should also be able to control whether spaces are preserved by
> > registering an LSSerializerFilter.
> >
> > When I added one to your test program:
> >
> > if (useXerces)
> > {
> > domWriter = new DOMSerializerImpl();
> > domWriter.setFilter(new LSSerializerFilter() {
> > public int getWhatToShow() {
> > return LSSerializerFilter.SHOW_ALL;
> > }
> > public short acceptNode(Node n) {
> > return LSSerializerFilter.FILTER_ACCEPT;
> > }});
> > }
> >
> > the output I get is:
> >
> >
> > Program started
> > Xerces serializer will be used
> > <?xml version="1.0" encoding="UTF-16"?>
> > <root>
> > <child1>text</child1>
> > <child2> </child2>
> >
> > </root>
> >
> > Xalan serializer will be used
> > <?xml version="1.0" encoding="UTF-16"?><root>
> > <child1>text</child1>
> > <child2> </child2>
> > </root>
>
> > which I believe is what you were expecting.
> >
> > Thanks.
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
> > Dick Deneer <dick.deneer@donkeydevelopment.com> wrote on 11/21/2009
> > 01:19:27 PM:
> >
> >
> > > Hi Jake,
> > >
> > >
> > > I just tried your suggestion and the spaces are indeed preserved.
> > > But still, I woud prefer another solution. I do not have any clue
> > > about the xml (I use xerces in a xml editor) and I do not want to
> > > change the xml.
> > > And also I would like to stay with the LSSerializer (it also
> > > serilalizes doctype nodes).
> > > If there is another way please let me know.
> > >
> > > Thanks
> > > Dick Deneer
> > >
> > >
> > >
> > > Op 21-nov-2009, om 19:03 heeft Jacob Kjome het volgende geschreven:
> > >
> > > > Have you tried xml:space="preserve"?
> > > >
> > > > Jake
> > > >
> > > > On 11/20/2009 4:36 PM, Dick Deneer wrote:
> > > >> I am still using the deprecated LSSerializer because the xalan
> > > >> serializer has issues with the pretty print.
> > > >> But when I have simple elements with only space, the serializer
> > > >> produces
> > > >> empty elements. Is there a tweak to keep the spaces in this
elements?
> > > >>
> > > >> Sample xml:
> > > >> <root><child1>text</child1><child2> </child2></root>
> > > >> I attached a simple test program, that you can just run to see the
> > > >> results:
> > > >>
> > > >> Program started
> > > >> Xerces serializer will be used
> > > >> <?xml version="1.0" encoding="UTF-16"?>
> > > >> <root>
> > > >> <child1>text</child1>
> > > >> <child2/>
> > > >> </root>
> > > >>
> > > >> Xalan serializer will be used
> > > >> <?xml version="1.0" encoding="UTF-16"?><root>
> > > >> <child1>text</child1>
> > > >> <child2> </child2>
> > > >> </root>
> > > >>
> > > >> Regards
> > > >> Dick Deneer
> > > >>
> > > >>
---------------------------------------------------------------------
> > > >> ---
> > > >>
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > > > For additional commands, e-mail: j-users-help@xerces.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > > For additional commands, e-mail: j-users-help@xerces.apache.org
Hi Michael,
So, if I put Xerces and not Xalan into classpath, and ask a document for
it's implementation, and ask that for the DOMImplementationLS, what do I
get? Whatever Sun tossed into the pot? And if I then add Xalan, do I get the
right one?
--benson
On Sat, Nov 21, 2009 at 10:24 PM, Michael Glavassevich
<mrglavas@ca.ibm.com>wrote:
> Hi Benson,
>
> We're talking about two different implementations of the DOM Level 3
> LSSerializer, the more recently developed one in Xalan (serializer.jar which
> Xerces now ships and shares with Xalan) and the much older deprecated one in
> Xerces. If you're curious about the history on that, there's an FAQ [1] on
> the website.
>
> Some users have decided to keep using Xerces' deprecated serializer due to
> some quirks and issues with the currently available one from Xalan. Folks
> really should be opening JIRA issues [2] against Xalan, so those problems
> get addressed there. There's no intention to do any further development or
> fixes to the one in Xerces.
>
> Thanks.
>
> [1] http://xerces.apache.org/xerces2-j/faq-general.html#faq-6
> [2] https://issues.apache.org/jira/browse/XALANJ
>
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Benson Margulies <bimargulies@gmail.com> wrote on 11/21/2009 02:17:49 PM:
>
>
> > Could I please ask for a bit of clarification? The only LSSerializer
> > I'm aware of is the DOM level 3 stuff, which, I thought, was the
> > opposite of obsolete. As someone pointed out here, unlike TraX, it
> > will serialize doctypes and do other handy things. In general, I'm
> > beginning to prefer the DOMImplementationLS to JAXP and TraX.
>
> > On Sat, Nov 21, 2009 at 2:07 PM, Michael Glavassevich <
> mrglavas@ca.ibm.com
> > > wrote:
> > You should also be able to control whether spaces are preserved by
> > registering an LSSerializerFilter.
> >
> > When I added one to your test program:
> >
> > if (useXerces)
> > {
> > domWriter = new DOMSerializerImpl();
> > domWriter.setFilter(new LSSerializerFilter() {
> > public int getWhatToShow() {
> > return LSSerializerFilter.SHOW_ALL;
> > }
> > public short acceptNode(Node n) {
> > return LSSerializerFilter.FILTER_ACCEPT;
> > }});
> > }
> >
> > the output I get is:
> >
> >
> > Program started
> > Xerces serializer will be used
> > <?xml version="1.0" encoding="UTF-16"?>
> > <root>
> > <child1>text</child1>
> > <child2> </child2>
> >
> > </root>
> >
> > Xalan serializer will be used
> > <?xml version="1.0" encoding="UTF-16"?><root>
> > <child1>text</child1>
> > <child2> </child2>
> > </root>
>
> > which I believe is what you were expecting.
> >
> > Thanks.
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail: mrglavas@ca.ibm.com
> > E-mail: mrglavas@apache.org
> >
> > Dick Deneer <dick.deneer@donkeydevelopment.com> wrote on 11/21/2009
> > 01:19:27 PM:
> >
> >
> > > Hi Jake,
> > >
> > >
> > > I just tried your suggestion and the spaces are indeed preserved.
> > > But still, I woud prefer another solution. I do not have any clue
> > > about the xml (I use xerces in a xml editor) and I do not want to
> > > change the xml.
> > > And also I would like to stay with the LSSerializer (it also
> > > serilalizes doctype nodes).
> > > If there is another way please let me know.
> > >
> > > Thanks
> > > Dick Deneer
> > >
> > >
> > >
> > > Op 21-nov-2009, om 19:03 heeft Jacob Kjome het volgende geschreven:
> > >
> > > > Have you tried xml:space="preserve"?
> > > >
> > > > Jake
> > > >
> > > > On 11/20/2009 4:36 PM, Dick Deneer wrote:
> > > >> I am still using the deprecated LSSerializer because the xalan
> > > >> serializer has issues with the pretty print.
> > > >> But when I have simple elements with only space, the serializer
> > > >> produces
> > > >> empty elements. Is there a tweak to keep the spaces in this
> elements?
> > > >>
> > > >> Sample xml:
> > > >> <root><child1>text</child1><child2> </child2></root>
> > > >> I attached a simple test program, that you can just run to see the
> > > >> results:
> > > >>
> > > >> Program started
> > > >> Xerces serializer will be used
> > > >> <?xml version="1.0" encoding="UTF-16"?>
> > > >> <root>
> > > >> <child1>text</child1>
> > > >> <child2/>
> > > >> </root>
> > > >>
> > > >> Xalan serializer will be used
> > > >> <?xml version="1.0" encoding="UTF-16"?><root>
> > > >> <child1>text</child1>
> > > >> <child2> </child2>
> > > >> </root>
> > > >>
> > > >> Regards
> > > >> Dick Deneer
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> ---
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > > > For additional commands, e-mail: j-users-help@xerces.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > > For additional commands, e-mail: j-users-help@xerces.apache.org
>
Content-type: text/plain; charset=US-ASCII (Copying xalan-j-users to this thread.) Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@ca.ibm.com E-mail: mrglavas@apache.org Michael Glavassevich <mrglavas@ca.ibm.com> wrote on 11/22/2009 10:30:49 AM: > Dick Deneer <dick.deneer@donkeydevelopment.com> wrote on 11/22/2009 > 06:33:28 AM: > > > Michael, > > > > Thank you for this suggestion. > > I can use this. Before I call the serializer I will strip off all > > whitespace in "whitespace-only" complex nodes because otherwise I do > > not get a pretty-print: > > For example: > > String xml = "<root>" + > > " <child1>text</child1><child2> > > </child2></root>"; > > results in : > > <?xml version="1.0" encoding="UTF-16"?> > > <root> <child1>text</child1> > > <child2> </child2> > > </root> > > > > But stripping of this whitespace before will not be too difficult. > > > > I feel it is a pitty that the LSSerializer will not be maintained > > anymore, because we do not have alternatives that supply the same > > functionality. > > It is in Xalan. Their serializer started as a copy of the Xerces one > (even has similar package names: org.apache.xml.serialize vs. > org.apache.xml.serializer). We didn't want to duplicate the effort > anymore and decided to combine forces and the Xalan one was chosen > as the common codebase because it was better maintained and was > making significant improvements to performance. Its LSSerializer > implementation was written by a Xerces committer and I have made > improvements and fixes to it too where I've found issues, so it's > being jointly maintained, though in a different project. This is the > alternative. It *is* an LSSerializer and there is no reason that it > can't be updated / fixed to have similar behaviour, but that's only > likely to happen if users report the problems they're having > (patches are welcome), preferably in JIRA. > > > I am afraid that maybe in the future there may be new xml (or DOM) > > feautures that have effects on the serialization. Then we are > > totally dependent on other libraries to implement that functionality. > > > > But I understand you have to make choices where to spent the effort. > > > > Thanks > > Dick Deneer > > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrglavas@ca.ibm.com > E-mail: mrglavas@apache.org
I originally posted this question to the FOP users list,
http://thread.gmane.org/gmane.text.xml.fop.user/29778
I'm writing a stylesheet that includes this template,
<xsl:template match="html:img">
<fo:external-graphic src="url('{@src}')"/>
</xsl:template>
- but when I process it I get errors like,
$ fop -xml index.html -xsl index.xsl index.pdf
[...]
16-Nov-2009 11:06:32 AM org.apache.fop.events.LoggingEventListener processEvent
SEVERE: Image not found. URI: /docs/images/thumb/b/bb/UM-2.1.png/500px-UM-2.1.png. (No context
info available)
[...]
- and the generated PDF is missing some images : (
I think the problem is that the stylesheet uses the document() function
to get HTML pages from the web,
<xsl:template match="html:a" mode="foo">
<fo:block>
<xsl:apply-templates select="document(@href)//html:body"/>
</fo:block>
</xsl:template>
- and these pages, e.g. http://ica-atom.org/docs/index.php?title=UM-2.1
- have some relative images,
e.g. /docs/images/thumb/b/bb/UM-2.1.png/500px-UM-2.1.png
The <img> elements are part of the HTML document, and so relative to
http://ica-atom.org/docs/index.php?title=UM-2.1, but I guess the
<external-graphic> elements aren't?
I tried adding an xml:base="" attribute,
<xsl:template match="html:a" mode="foo">
<fo:block xml:base="{@href}">
<xsl:apply-templates select="document(@href)//html:body"/>
</fo:block>
</xsl:template>
Here's a simplified, complete example,
http://www.sfu.ca/~jdbates/tmp/fop/200911160/index.html
http://www.sfu.ca/~jdbates/tmp/fop/200911160/index.xsl
- but now when I process this example I get this error,
$ fop -xml index.html -xsl index.xsl index.pdf
16-Nov-2009 11:29:57 AM org.apache.fop.cli.Main startFOP
SEVERE: Exception
javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: Invalid
property encountered on "fo:block": xml:base (No context info available)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:314)
at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:146)
at org.apache.fop.cli.Main.startFOP(Main.java:174)
at org.apache.fop.cli.Main.main(Main.java:205)
[...]
How can I automatically convert these HTML pages to a PDF with XSL-FO?
> Can anyone tell me if there's any way to add an object (not node or > tree fragment) variable to the variable stack from an extension element? >From an extension _element_... I don't think so. >From an extension _function_, yes. If the returned value is not an instanceof one of the types called out in the mapping table ( http://xml.apache.org/xalan-j/extensions.html#ext-functions), it will be returned as an object reference. Generally you can't do much with those except store them in variables and/or pass them as parameters to other extensions. If your returned value *is* an instanceof one of those types... The best suggestion I can give you is to set up a wrapper object which does not implement those types, return the wrapper, and have whoever is using the value unwrap it again before accessing it.
Can anyone tell me if there's any way to add an object (not node or tree fragment) variable
to the variable stack from an extension element?
I originally tried to use context.outputToResultTree(context.getStylesheet(), myCreatedObject)
an put my extension element inside an <xsl:variable...>, however that turns my java
object into a text node on a Document first (the text node has the value of the toString()
from my object) rather than passing myCreatedObject to the ElemVariable element as a java
object.
I'm now looking into doing a similar thing as in ElemVariable.java and adding the object to
the stack directly from within my extension element method, from what I can see, this should
work:
StylesheetRoot root = xslProcessorContext.getStylesheet().getStylesheetRoot();
StylesheetRoot.ComposeState cstate = sroot.getComposeState();
QName name = new QName(name);
XObject obj = new XObject(myCreatedObject);
int index = cstate.addVariableName(name) - cstate.getGlobalsSize();
xslProcessorContext.getTransformer().getXPathContext().getVarStack().setLocalVariable(index,
obj);
Now this is similar to what ElemVariable.java does, however StylesheetRoot.ComposeState is
package scoped!, so I can't use the above code either :(
If anyone knows of a way to put a java object variable onto the variable stack (as an XObject,
not a XRTreeFrag) under a given name from within an extension element method I'd really appreciate
any pointers you could give.
My goals is placing an object into the local variable stack under a given name so that I can
reference it, for example in an <xsl:value-of select="java:someMethod($myPreviouslyAddedObject)"/>
--- On Fri, 13/11/09, Adam Jenkins <adamjenkinstmpredirect@yahoo.com.au> wrote:
> From: Adam Jenkins <adamjenkinstmpredirect@yahoo.com.au>
> Subject: Advanced Extension Element Question
> To: xalan-j-users@xml.apache.org, xalan-dev@xml.apache.org
> Received: Friday, 13 November, 2009, 5:53 PM
> Hi All,
>
> I'm just wondering if there is a way to place a java object
> (not a tree fragment) into the context output results from
> an extension element, and have it stay as an object (and not
> have it turned into a Document node).
>
> Here is the exact use case. I have a custom extension
> that creates an object that is used later on throughout my
> xslt. The use case I want is:
>
> <xsl:variable name="somevarname">
> <custom:myobject>
> <custom:property name="blah"
> value="blah"/>
> </custom:myobject>
> </xsl:variable>
>
> The function myObject(XSLProcessorContext,
> ElemExtensionCall) on the object mapped to the prefix
> 'custom' creates a java object, and places it to the output
> tree thus:
>
> context.outputToResultTree(context.getStylesheet(),
> myCreatedObject);
>
> Now, when I try to reference that later, it's been turned
> into a text node on a Document object whos value is the
> value of the toString() method for 'myCreatedObject'.
> So I think I'm using the wrong method here...and that
> perhaps there's a better method other than
> outputToResultTree??
>
> So I'm guessing xalan <xsl:variable...> tag is
> creating a document fragment from my object as best it can.
>
> So my question is...is there anyway, to pass
> myCreatedObject up to the previous <xsl:variable...>
> declaration without it being toStringed (another method
> somewhere).
>
> My fallback is to declare a varName attribute on all my
> custom extension and put the object on the local variable
> stack myself, but that's a pain and looks ugly, I'd prefer
> to do it using xsl:variable.
>
> This is for an open source (large) xalan extension library
> to be releases asap.
>
> Cheers
> Adam
>
>
>
> __________________________________________________________________________________
> Win 1 of 4 Sony home entertainment packs thanks to
> Yahoo!7.
> Enter now: http://au.docs.yahoo.com/homepageset/
>
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
Hi all,
I am using Xalan-J 2.7.1 from the command line via the
org.apache.xalan.xslt.Process class. I have noticed that <xsl:message
terminate="yes"> is no longer terminating the processing of the
stylesheet. Instead the processor continues running and statements that
come after the terminating <xsl:message> get processed. The termination
is handled the way you'd expect in 2.7.0 and earlier versions.
Test stylesheet:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:message terminate="yes">Terminating here...</xsl:message>
<xsl:value-of select="'This should not be processed!'"/>
</xsl:template>
</xsl:stylesheet>
When I run this via org.apache.xalan.xslt.Process, I get the termination
message ("Terminating here...") along with the line and column number
information, but then it continues running and I see the second line of
output ("This should not be processed!").
I understand that Process uses the DefaultErrorHandler class, and that
according to the release notes for Xalan 2.7.0 (see
http://xml.apache.org/xalan-j/readme.html, the "New default error
handling behavior" section), the default ErrorListener was changed so
that it no longer throws exceptions on errors or fatal errors. However
in 2.7.0 the org.apache.xalan.xslt.Process still worked as expected,
without any modifications.
This bug fix introduced the change in behavior of Process between 2.7.0
and 2.7.1:
http://issues.apache.org/jira/secure/ViewIssue.jspa?key=XALANJ-2317.
Process went from instantiating DefaultErrorHandler with
m_throwExceptionOnError=true to instantiating it with
m_throwExceptionOnError=false. There were good reasons (I suppose) for
making that change, but it seems to break the default handling of
<xsl:message terminate="yes">.
I was somewhat surprised to see that org.apache.xalan.xslt.Process was
showing incorrect default behavior for <xsl:message terminate="yes">
right out of the box. Is this a bug or is this known/expected and I just
need to alter Process myself or use my own error handler? I can simply
"fix" this for my own uses by changing Processs to use "new
DefaultErrorHandler(true)" but I'm worried about undoing the fixes for
the problems listed in bug #2317.
I wanted to post to the mailing list before I tried submitting a bug
report and working on a possible patch, to see if this was an actual
problem or not.
Thanks for your help,
--
Nathan Nadeau
ndn@gleim.com
Software Development
Gleim Publications, Inc.
http://www.gleim.com
----- "Michael Ludwig" <milu71@gmx.de> wrote:
> From: "Michael Ludwig" <milu71@gmx.de>
> To: xalan-j-users@xml.apache.org
> Sent: Thursday, November 12, 2009 7:08:24 PM GMT -07:00 US/Canada Mountain
> Subject: Re: Stream Closed on xsl transformation
>
> Trenton D. Adams schrieb am 12.11.2009 um 16:19:35 (-0700):
> > I didn't send an attachment, I sent a link. Do links get removed
> too?
>
> I must have been very tired when looking for the attachment.
>
> > As for it being 10k, the important part is that it does not work
> with
> > a processing instruction of "<?xml-stylesheet...?>", but does work
> > without one (i.e. specifying one in the java code). It's not the
> > XML/XSLT that is important to look at, but the Java code, which is
> > very small, and easy to follow, especially considering it's a
> simple
> > JUnit test.
>
> Maybe, but it is way more complex than it should have to be.
>
> Anyway, I get two failures because of:
>
> junit.framework.AssertionFailedError
> caused by
> javax.xml.transform.TransformerException
> caused by
> java.net.UnknownHostException
>
> And it is little wonder as your stylesheet PI misses a valid URI:
>
> <?xml-stylesheet type="text/xsl"
> href="file://${basedir}/target/test-classes/transcript.xsl"?>
>
> Corrected this to:
>
> http://localhost/g/xml-util/target/test-classes/transcript.xsl
Yeah, that's because it's setup to use maven filtering. You have to actually run it through
maven to work. It replaces "basedir" with an appropriate path.
>
> Now:
>
> junit.framework.AssertionFailedError
> caused by
> java.io.IOException: Stream closed
>
> Okay, the error is in reading the PI from the StreamSource by calling
> getAssociatedStylesheet(), and then trying to read again from the
> same
> StreamSource by calling transform(). Streams are to be used once
> only.
Oh yes, in my rush to get a project done here, I hadn't though of the fact that you can't
use the source twice; which is duh, it uses a stream, hehe. Silly me.
>
> Fixing this in your program is cumbersome, because you have one big
> method with parameters of type Object which you then cast to whatever
> you need based on what instanceof tells you.
>
> public static String xslTransformation(
> final Object xml,
> final Object xsl,
> final Map parameters )
>
> What's wrong with using polymorphism instead? It's vastly superior.
Well, v0.1.X is just a hack to get things done until I have time to fix it all up properly.
That is initial development, it isn't always pretty.
>
> Also, please consider providing simple test cases. You'd have
> discovered
> this error yourself if you had taken the time to build a simple test
> case without so many complicating ingredients. It bears repeating
> here
> that simplifying is a basic problem solving technique.
I don't think it had much to do with the complexity of the code, as it isn't very complex.
It had a lot more to do with rushing through.
Thanks for the suggestions though.
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
Hi All,
I'm just wondering if there is a way to place a java object (not a tree fragment) into the
context output results from an extension element, and have it stay as an object (and not have
it turned into a Document node).
Here is the exact use case. I have a custom extension that creates an object that is used
later on throughout my xslt. The use case I want is:
<xsl:variable name="somevarname">
<custom:myobject>
<custom:property name="blah" value="blah"/>
</custom:myobject>
</xsl:variable>
The function myObject(XSLProcessorContext, ElemExtensionCall) on the object mapped to the
prefix 'custom' creates a java object, and places it to the output tree thus:
context.outputToResultTree(context.getStylesheet(), myCreatedObject);
Now, when I try to reference that later, it's been turned into a text node on a Document object
whos value is the value of the toString() method for 'myCreatedObject'. So I think I'm using
the wrong method here...and that perhaps there's a better method other than outputToResultTree??
So I'm guessing xalan <xsl:variable...> tag is creating a document fragment from my
object as best it can.
So my question is...is there anyway, to pass myCreatedObject up to the previous <xsl:variable...>
declaration without it being toStringed (another method somewhere).
My fallback is to declare a varName attribute on all my custom extension and put the object
on the local variable stack myself, but that's a pain and looks ugly, I'd prefer to do it
using xsl:variable.
This is for an open source (large) xalan extension library to be releases asap.
Cheers
Adam
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
Trenton D. Adams schrieb am 12.11.2009 um 16:19:35 (-0700):
> I didn't send an attachment, I sent a link. Do links get removed too?
I must have been very tired when looking for the attachment.
> As for it being 10k, the important part is that it does not work with
> a processing instruction of "<?xml-stylesheet...?>", but does work
> without one (i.e. specifying one in the java code). It's not the
> XML/XSLT that is important to look at, but the Java code, which is
> very small, and easy to follow, especially considering it's a simple
> JUnit test.
Maybe, but it is way more complex than it should have to be.
Anyway, I get two failures because of:
junit.framework.AssertionFailedError
caused by
javax.xml.transform.TransformerException
caused by
java.net.UnknownHostException
And it is little wonder as your stylesheet PI misses a valid URI:
<?xml-stylesheet type="text/xsl"
href="file://${basedir}/target/test-classes/transcript.xsl"?>
Corrected this to:
http://localhost/g/xml-util/target/test-classes/transcript.xsl
Now:
junit.framework.AssertionFailedError
caused by
java.io.IOException: Stream closed
Okay, the error is in reading the PI from the StreamSource by calling
getAssociatedStylesheet(), and then trying to read again from the same
StreamSource by calling transform(). Streams are to be used once only.
Fixing this in your program is cumbersome, because you have one big
method with parameters of type Object which you then cast to whatever
you need based on what instanceof tells you.
public static String xslTransformation(
final Object xml,
final Object xsl,
final Map parameters )
What's wrong with using polymorphism instead? It's vastly superior.
Also, please consider providing simple test cases. You'd have discovered
this error yourself if you had taken the time to build a simple test
case without so many complicating ingredients. It bears repeating here
that simplifying is a basic problem solving technique.
Best,
--
Michael Ludwig
I didn't send an attachment, I sent a link. Do links get removed too?
http:// www.trentonadams.ca /xml-util.tar.gz
As for it being 10k, the important part is that it does not work with a processing instruction
of "<?xml-stylesheet...?>", but does work without one (i.e. specifying one in the java
code). It's not the XML/XSLT that is important to look at, but the Java code, which is very
small, and easy to follow, especially considering it's a simple JUnit test.
Thanks.
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
----- "Michael Ludwig" <milu71@gmx.de> wrote:
> From: "Michael Ludwig" <milu71@gmx.de>
> To: xalan-j-users@xml.apache.org
> Sent: Wednesday, November 11, 2009 5:10:52 AM GMT -07:00 US/Canada Mountain
> Subject: Re: Stream Closed on xsl transformation
>
> Trenton D. Adams schrieb am 07.11.2009 um 16:09:07 (-0700):
> > Hi Michael
> >
> > Here is a 10K tar.gz file of a test case with a maven build
> project.
>
> Hi Trenton,
>
> it looks like the attachment didn't make it to the list. Anyway, 10
> KB
> of gzipped text is not exactly small. I would have thought of a
> simple
> main() style test case.
>
> Best,
>
> --
> Michael Ludwig
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
Apache lists strip attachments. I suppose you could open a JIRA and attach it there. On Wed, Nov 11, 2009 at 7:10 AM, Michael Ludwig <milu71@gmx.de> wrote: > Trenton D. Adams schrieb am 07.11.2009 um 16:09:07 (-0700): > > Hi Michael > > > > Here is a 10K tar.gz file of a test case with a maven build project. > > Hi Trenton, > > it looks like the attachment didn't make it to the list. Anyway, 10 KB > of gzipped text is not exactly small. I would have thought of a simple > main() style test case. > > Best, > > -- > Michael Ludwig >
Jack Bates schrieb am 10.11.2009 um 13:08:16 (-0800):
>
> When I pass a relative URL to the "document()" function, it resolved
> to the wrong absolute URL, e.g. "/home/jablko/index.php"
>
> So I tried using xml:base, e.g.
> <xsl:apply-templates xml:base="http://ica-atom.org/docs/"
> select="document('index.php?title=User_manual')/html:html"/>
> ^ This works great with xsltproc,
> - but not Xalan,
> Is it a bug that Xalan appears to ignore xml:base?
Xalan claims to support XPath 1.0 and XSLT 1.0.
http://xml.apache.org/xalan-j/index.html
As far as I can see, Xalan makes no claim to supporting xml:base, which
is one of the add-ons to XML.
There is a Xalan bug pertaining to incorrect base URIs as a result of
failing to track the physical structure of an XML document (external
entities), which seems to support the above assessment, which I trust
the experts will correct if incorrect.
http://issues.apache.org/jira/browse/XALANJ-2274
> Any advice on resolving relative URLs?
See javax.xml.transform.URIResolver. Implement and register your own URI
resolver.
Best,
--
Michael Ludwig
Trenton D. Adams schrieb am 07.11.2009 um 16:09:07 (-0700): > Hi Michael > > Here is a 10K tar.gz file of a test case with a maven build project. Hi Trenton, it looks like the attachment didn't make it to the list. Anyway, 10 KB of gzipped text is not exactly small. I would have thought of a simple main() style test case. Best, -- Michael Ludwig
I'm processing XML which contains relative URLs, e.g
"index.php?title=User_manual", and want to apply templates to the
referenced resources
I'm trying to do so with the "document()" function
When I pass a relative URL to the "document()" function, it resolved to
the wrong absolute URL, e.g. "/home/jablko/index.php"
So I tried using xml:base, e.g.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:apply-templates xml:base="http://ica-atom.org/docs/" select="document('index.php?title=User_manual')/html:html"/>
</xsl:template>
</xsl:stylesheet>
http://www.sfu.ca/~jdbates/tmp/xalan/200911090/test.xsl
^ This works great with xsltproc,
$ xsltproc test.xsl test.xsl
[...]
$
- but not Xalan,
$ java -jar xalan-j_2_7_1/xalan.jar -IN test.xsl -XSL test.xsl
file:///home/jablko/test.xsl; Line #4; Column #123; Can not load requested doc: /home/jablko/index.php
(No such file or directory)
<?xml version="1.0" encoding="UTF-8"?>$
Any advice on resolving relative URLs?
Is it a bug that Xalan appears to ignore xml:base?
I do have the java 1.4 restriction set in the pom, but I figured I'd give you my exact java
version...
java version "1.4.2-03"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-03)
Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-03, mixed mode)
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
----- "Trenton D. Adams" <trenta@athabascau.ca> wrote:
> From: "Trenton D. Adams" <trenta@athabascau.ca>
> To: "Michael Ludwig" <milu71@gmx.de>
> Cc: xalan-j-users@xml.apache.org
> Sent: Saturday, November 7, 2009 4:09:07 PM GMT -07:00 US/Canada Mountain
> Subject: Re: Stream Closed on xsl transformation
>
> Hi Michael
>
> Here is a 10K tar.gz file of a test case with a maven build project.
> Run with the "test" profile, as in...
>
> mvn -P test install
>
> The full stack trace is in xml-util.log.
>
> Take note of the comment in XMLUtil.java:167, as I can get it to work
> if I convert to a DOMSource instead.
>
> http://www.trentonadams.ca/xml-util.tar.gz
>
> Thanks.
>
> Trenton D. Adams
> Systems Analyst/Web Software Engineer
> Navy Penguins at your service!
> Athabasca University
> (780) 675-6195
> :wq!
>
> ----- "Michael Ludwig" <milu71@gmx.de> wrote:
>
> > From: "Michael Ludwig" <milu71@gmx.de>
> > To: xalan-j-users@xml.apache.org
> > Sent: Thursday, November 5, 2009 6:08:04 PM GMT -07:00 US/Canada
> Mountain
> > Subject: Re: Stream Closed on xsl transformation
> >
> > Hi Trenton,
> >
> > Trenton D. Adams schrieb am 05.11.2009 um 13:00:00 (-0700):
> >
> > > I'm having some strange problems with a stream being closed when
> I
> > do
> > > an XSL transformation on an XML document that has an
> xml-stylesheet
> > > that is at a remote location. If I instead put it locally, and
> and
> > > specify it as an xsltSource, it works fine.
> > >
> > > I have also narrowed it down to the following working...
> > > final Document doc = stringToDocument((String) xml);
> > > logger.debug(documentToString(doc));
> > > xmlSource = new DOMSource(doc);
> > >
> > > But not this...
> > > xmlSource = new StreamSource(new
> StringReader((String)
> > xml));
> >
> > This approach works fine for me as in:
> >
> > Source src = new StreamSource(new StringReader("<Urmel/>"));
> >
> > > I get a stack trace like the following; where the final "Caused
> by"
> > > indicates it has a problem with the StringReader in the second
> > example
> > > above. But, my stringToDocument() method also does a
> StringReader.
> >
> > > Caused by: java.io.IOException: Stream closed
>
> >
> > > at java.io.StringReader.ensureOpen(StringReader.java:39)
>
> >
> > > at java.io.StringReader.read(StringReader.java:73)
>
> >
> > > at
> >
> org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(XMLEntityManager.java:3257)
> >
> > The exception seems to occur in a large program. There must be
> > something
> > wrong in those lines that you haven't shown. Rather than posting
> the
> > massive program, try boiling it down to a small, self-contained
> test
> > case. If the error persists, you might want to post the small test
> > program.
> >
> > Best,
> >
> > Michael Ludwig
>
> __
> This communication is intended for the use of the recipient to
> whom it
> is addressed, and may contain confidential, personal, and or
> privileged
> information. Please contact us immediately if you are not the
> intended
> recipient of this communication, and do not copy, distribute, or
> take
> action relying on it. Any communications received in error, or
> subsequent reply, should be deleted or destroyed.
> ---
Hi Michael
Here is a 10K tar.gz file of a test case with a maven build project. Run with the "test"
profile, as in...
mvn -P test install
The full stack trace is in xml-util.log.
Take note of the comment in XMLUtil.java:167, as I can get it to work if I convert to a DOMSource
instead.
http://www.trentonadams.ca/xml-util.tar.gz
Thanks.
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
----- "Michael Ludwig" <milu71@gmx.de> wrote:
> From: "Michael Ludwig" <milu71@gmx.de>
> To: xalan-j-users@xml.apache.org
> Sent: Thursday, November 5, 2009 6:08:04 PM GMT -07:00 US/Canada Mountain
> Subject: Re: Stream Closed on xsl transformation
>
> Hi Trenton,
>
> Trenton D. Adams schrieb am 05.11.2009 um 13:00:00 (-0700):
>
> > I'm having some strange problems with a stream being closed when I
> do
> > an XSL transformation on an XML document that has an xml-stylesheet
> > that is at a remote location. If I instead put it locally, and and
> > specify it as an xsltSource, it works fine.
> >
> > I have also narrowed it down to the following working...
> > final Document doc = stringToDocument((String) xml);
> > logger.debug(documentToString(doc));
> > xmlSource = new DOMSource(doc);
> >
> > But not this...
> > xmlSource = new StreamSource(new StringReader((String)
> xml));
>
> This approach works fine for me as in:
>
> Source src = new StreamSource(new StringReader("<Urmel/>"));
>
> > I get a stack trace like the following; where the final "Caused by"
> > indicates it has a problem with the StringReader in the second
> example
> > above. But, my stringToDocument() method also does a StringReader.
>
> > Caused by: java.io.IOException: Stream closed
>
> > at java.io.StringReader.ensureOpen(StringReader.java:39)
>
> > at java.io.StringReader.read(StringReader.java:73)
>
> > at
> org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(XMLEntityManager.java:3257)
>
> The exception seems to occur in a large program. There must be
> something
> wrong in those lines that you haven't shown. Rather than posting the
> massive program, try boiling it down to a small, self-contained test
> case. If the error persists, you might want to post the small test
> program.
>
> Best,
>
> Michael Ludwig
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
Hi Michael,
----- "Michael Ludwig" <milu71@gmx.de> wrote:
> From: "Michael Ludwig" <milu71@gmx.de>
> To: xalan-j-users@xml.apache.org
> Sent: Thursday, November 5, 2009 6:08:04 PM GMT -07:00 US/Canada Mountain
> Subject: Re: Stream Closed on xsl transformation
>
> Hi Trenton,
>
> Trenton D. Adams schrieb am 05.11.2009 um 13:00:00 (-0700):
>
> > I'm having some strange problems with a stream being closed when I
> do
> > an XSL transformation on an XML document that has an xml-stylesheet
> > that is at a remote location. If I instead put it locally, and and
> > specify it as an xsltSource, it works fine.
> >
> > I have also narrowed it down to the following working...
> > final Document doc = stringToDocument((String) xml);
> > logger.debug(documentToString(doc));
> > xmlSource = new DOMSource(doc);
> >
> > But not this...
> > xmlSource = new StreamSource(new StringReader((String)
> xml));
>
> This approach works fine for me as in:
>
> Source src = new StreamSource(new StringReader("<Urmel/>"));
Yeah, that wouldn't be a problem, as it does not have an xml-stylesheet processing instruction.
>
> > I get a stack trace like the following; where the final "Caused by"
> > indicates it has a problem with the StringReader in the second
> example
> > above. But, my stringToDocument() method also does a StringReader.
>
> > Caused by: java.io.IOException: Stream closed
>
> > at java.io.StringReader.ensureOpen(StringReader.java:39)
>
> > at java.io.StringReader.read(StringReader.java:73)
>
> > at
> org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(XMLEntityManager.java:3257)
>
> The exception seems to occur in a large program. There must be
> something
> wrong in those lines that you haven't shown. Rather than posting the
> massive program, try boiling it down to a small, self-contained test
> case. If the error persists, you might want to post the small test
> program.
Yes, I did narrow it down to a small test case (or semi-small, the xml/xslt isn't so small).
I will see if I can provide it when I get to work tomorrow. I'll also see if I can make
it happen with a smaller XML/XSLT.
>
> Best,
>
> Michael Ludwig
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
Hi Trenton,
Trenton D. Adams schrieb am 05.11.2009 um 13:00:00 (-0700):
> I'm having some strange problems with a stream being closed when I do
> an XSL transformation on an XML document that has an xml-stylesheet
> that is at a remote location. If I instead put it locally, and and
> specify it as an xsltSource, it works fine.
>
> I have also narrowed it down to the following working...
> final Document doc = stringToDocument((String) xml);
> logger.debug(documentToString(doc));
> xmlSource = new DOMSource(doc);
>
> But not this...
> xmlSource = new StreamSource(new StringReader((String) xml));
This approach works fine for me as in:
Source src = new StreamSource(new StringReader("<Urmel/>"));
> I get a stack trace like the following; where the final "Caused by"
> indicates it has a problem with the StringReader in the second example
> above. But, my stringToDocument() method also does a StringReader.
> Caused by: java.io.IOException: Stream closed
> at java.io.StringReader.ensureOpen(StringReader.java:39)
> at java.io.StringReader.read(StringReader.java:73)
> at org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(XMLEntityManager.java:3257)
The exception seems to occur in a large program. There must be something
wrong in those lines that you haven't shown. Rather than posting the
massive program, try boiling it down to a small, self-contained test
case. If the error persists, you might want to post the small test
program.
Best,
Michael Ludwig
Hi Guys,
I'm having some strange problems with a stream being closed when I do an XSL transformation
on an XML document that has an xml-stylesheet that is at a remote location. If I instead
put it locally, and and specify it as an xsltSource, it works fine.
I have also narrowed it down to the following working...
final Document doc = stringToDocument((String) xml);
logger.debug(documentToString(doc));
xmlSource = new DOMSource(doc);
But not this...
xmlSource = new StreamSource(new StringReader((String) xml));
Any ideas why this wouldn't work?
I get a stack trace like the following; where the final "Caused by" indicates it has a problem
with the StringReader in the second example above. But, my stringToDocument() method also
does a StringReader.
Caused by: javax.xml.transform.TransformerException: java.io.IOException: Stream closed
at org.apache.xalan.transformer.TransformerImpl.fatalError(TransformerImpl.java:741)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:715)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1129)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1107)
at ca.athabascau.apas.xml.XMLUtil.xslTransformation(XMLUtil.java:226)
at ca.athabascau.apas.xml.XMLUtil.xslTransformation(XMLUtil.java:251)
at ca.athabascau.apas.IncomingTranscripts.processTranscript(IncomingTranscripts.java:348)
at ca.athabascau.apas.IncomingTranscripts.processWaitingTranscripts(IncomingTranscripts.java:107)
... 28 more
Caused by: java.io.IOException: Stream closed
at java.io.StringReader.ensureOpen(StringReader.java:39)
at java.io.StringReader.read(StringReader.java:73)
at org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(XMLEntityManager.java:3257)
at org.apache.xerces.impl.XMLEntityManager$EntityScanner.skipString(XMLEntityManager.java:3017)
at org.apache.xerces.impl.XMLDocumentScannerImpl$XMLDeclDispatcher.dispatch(XMLDocumentScannerImpl.java:577)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1169)
at org.apache.xml.dtm.ref.DTMManagerDefault.getDTM(DTMManagerDefault.java:495)
at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:658)
... 34 more
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
Benson, This could happen if Tomcat is bundling a different version of Xalan than the one you used to compile your webapp. You should check that. You can always bundle your own version of Xalan if classloading is set to support that in Tomcat. The Tomcat user list may be able to help you with that. -- Santiago On Nov 4, 2009, at 8:34 AM, Benson Margulies wrote: > I can provoke the following by trying to use Xalan inside of a Webapp > inside of Tomcat after using the JAXP 1.4 explicit newInstance to > obtain my factory. Confused doesn't begin to describe my reaction. Can > anyone give me a clue? Or a diagnostic procedure? > > java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.<init>(Z)V > org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207) > org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281) > org.apache.mtomcatbug.Serviette.doGet(Serviette.java:58) > javax.servlet.http.HttpServlet.service(HttpServlet.java:627) > javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
I can provoke the following by trying to use Xalan inside of a Webapp inside of Tomcat after using the JAXP 1.4 explicit newInstance to obtain my factory. Confused doesn't begin to describe my reaction. Can anyone give me a clue? Or a diagnostic procedure? java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.<init>(Z)V org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207) org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281) org.apache.mtomcatbug.Serviette.doGet(Serviette.java:58) javax.servlet.http.HttpServlet.service(HttpServlet.java:627) javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
Hi amitdk,
I tried to use your solution to pass a node-set to a translet and I don't
understand why, it does not work.
It's very strange but when I navigate in the node-set parameter, I get the
nodes of the XML source tree instead ! When I use a debugger, the
DTMAxisIterator passed as parameter seems ok, it contains in some deep
fields the content of the XML fragment I want to pass as parameter.
But I have to admit that understand how DTMxxx classes work is a real
nightmare for me.
Anyway, I don't understand why the official answer to this node-set
parameter passing problem is "known issue for XSLTC". When we have a look at
the BasisLibrary Xalan class, we can see that the referenceToNodeSet method
(called when a parameter is a node-set) exists and does some stuff to get a
DTMAxisIterator from either a org.apache.xalan.xsltc.runtime.Node (really
don't understand how to get this kind of object) or a DTMAxisIterator by
cloning it.
That means for me that the feature is available, am I wrong ?
Thanks for your help,
Eddy
amitdk wrote:
>
> Return DTMAxisIterator instead of XNodeSet. That should help solve the
> issue. Here's the method I use to convert a Document object and pass it as
> a parameter to the translet.
>
> private DTMAxisIterator convertDocumentToNodeSet(Document document)
> throws TransformerException
> {
>
> DOMSource domSource = new DOMSource(document);
> XSLTCDTMManager mgr = new XSLTCDTMManager();
> DTM dtm = mgr.getDTM(domSource, false, null, true, true);
> int dtmRoot = dtm.getDocument();
> DTMAxisIterator iter = dtm.getAxisIterator(Axis.SELF);
> iter.setStartNode(dtmRoot);
>
> return iter;
> }
>
--
View this message in context: http://old.nabble.com/How-can-I-pass-a-node-as-parameter-to-translets-for-XSLTC-Processor-tp8649149p26160041.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Vishal,
Xalan in the JDK is a compiler (XSLTC) and as such it tries to
resolve as much as it can statically. As a result, there are some
limitations. The discussion and resolution in [1] may help.
-- Santiago
[1] http://issues.apache.org/jira/browse/XALANJ-1485
On Nov 2, 2009, at 7:21 AM, Javalkar, Vishal wrote:
> Hi,
>
> Apparently, Xalan (the one bundled with JDK 6 at-least) complains
> when a java.util.Map is passed as a parameter to an XSLT stylesheet.
>
> Assuming, I have a snippet of code as:
>
> Map inputparam = new HashMap();
> inputparam.put("greeting", "hi there");
> transformer.setParameter("inputparam", inputparam);
> ...
> transformer.transform(...);
>
> and I have a simple XSLT that attempts to get the key 'greeting'
> from this
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:map="xalan://java.util.HashMap"
> extension-element-prefixes="map">
>
> <xsl:param name="inputparam" />
>
> <xsl:template match="/">
> <xsl:variable name="greeting"
> select="map:get($inputparam, 'greeting')" />
> <greeting><xsl:value-of select="greeting"/></greeting>
> </xsl:template>
> </xsl:stylesheet>
>
> I obtain the following error:
>
> ERROR: 'Cannot find external method 'java.util.HashMap.get' (must
> be public).'
> FATAL ERROR: 'Could not compile stylesheet'
> javax.xml.transform.TransformerConfigurationException: Could not
> compile stylesheet
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates
> (TransformerFactoryImpl.java:825)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer
> (TransformerFactoryImpl.java:614)
> at xalanxslttest.ExecuteXslt.main(ExecuteXslt.java:36)
>
>
> Is there a way to solve this? Is this supported?
>
> All help/advice appreciated!
> Thanks & Regards,
> Vishal
>
Hi,
Apparently, Xalan (the one bundled with JDK 6 at-least) complains when a java.util.Map is
passed as a parameter to an XSLT stylesheet.
Assuming, I have a snippet of code as:
Map inputparam = new HashMap();
inputparam.put("greeting", "hi there");
transformer.setParameter("inputparam", inputparam);
...
transformer.transform(...);
and I have a simple XSLT that attempts to get the key 'greeting' from this
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:map="xalan://java.util.HashMap"
extension-element-prefixes="map">
<xsl:param name="inputparam" />
<xsl:template match="/">
<xsl:variable name="greeting"
select="map:get($inputparam, 'greeting')" />
<greeting><xsl:value-of select="greeting"/></greeting>
</xsl:template>
</xsl:stylesheet>
I obtain the following error:
ERROR: 'Cannot find external method 'java.util.HashMap.get' (must be public).'
FATAL ERROR: 'Could not compile stylesheet'
javax.xml.transform.TransformerConfigurationException: Could not compile stylesheet
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:825)
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:614)
at xalanxslttest.ExecuteXslt.main(ExecuteXslt.java:36)
Is there a way to solve this? Is this supported?
All help/advice appreciated!
Thanks & Regards,
Vishal