Same XSLT produces different results?

[harryajh]

Using xalan 2.7.1 on Tomcat 5.5 & Weblogic 9.2 but I get different
results even though the same web app is deployed to each. The trouble
is the following xslt produces "<xsl:" tags on WL but "<xslt:" tags
(which is what I would expect!) on tomcat

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xslt="http://www.w3.org/1999/XSL/TransformAlias" version="1.0"
xmlns:gor="uk.gov.ea.gor.cache.GORCache">
<xsl:namespace-alias stylesheet-prefix="xslt" result-prefix="xsl"/>
<xsl:template match="/">
<xslt:stylesheet version="1.0" xmlns="http://www.w3.org/1999/xhtml">
<xsltutput method="xml" doctype-public="-//W3C//DTD XHTML 1.0
Transitional//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd"/>
<xslt:template match="/">
..

produces

<?xml version="1.0" encoding="UTF-8"?>
<xslt:stylesheet xmlns:xslt="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:gor="uk.gov.ea.gor.cache.GORCache" version="1.0">
<xsltutput doctype-system="http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd" doctype-public="-//W3C//DTD XHTML 1.0
Transitional//EN" method="xml"/>
<xslt:template match="/">
..

on Tomcat 5.5 BUT

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
Transform" xmlns:gor="uk.gov.ea.gor.cache.GORCache" xmlns="http://
www.w3.org/1999/xhtml">
<xslutput method="xml" doctype-public="-//W3C//DTD XHTML 1.0
Transitional//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/
xhtml1-transitional.dtd"/>
<xsl:template match="/">
..

on Weblogic 9.2

I'm using XSLT extension functions but can't believe this is anything
to do with it?

Can anyone shed some light on this? this is totally bizarre, how can
the same code produce different results? - is there something
different picked up from the environment perhaps? also noticed the
<stylesheet> attributes are generated in different orders also!

thanks in advance

harry

 

[Joseph Kesselman]

Namespace aliasing aliases *namespaces*, not necessarily prefixes per
se. There may be issues here regarding the details of proper copying of
namespace nodes -- I'd have to take a bit longer to look at that -- but
I'm not immediately convinced there's an error here. It may fall into
the category of "a difference that makes no difference is no difference".

 

[Martin Honnen]

Using xalan 2.7.1 on Tomcat 5.5 & Weblogic 9.2 but I get different
results even though the same web app is deployed to each. The trouble
is the following xslt produces "<xsl:" tags on WL but "<xslt:" tags
(which is what I would expect!) on tomcat

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xslt="http://www.w3.org/1999/XSL/TransformAlias" version="1.0"
xmlns:gor="uk.gov.ea.gor.cache.GORCache">
<xsl:namespace-alias stylesheet-prefix="xslt" result-prefix="xsl"/>
<xsl:template match="/">
<xslt:stylesheet version="1.0" xmlns="http://www.w3.org/1999/xhtml">

Can anyone shed some light on this? this is totally bizarre, how can
the same code produce different results? - is there something
different picked up from the environment perhaps? also noticed the
<stylesheet> attributes are generated in different orders also!

Attributes are not ordered in XML so you could get different orders (at
least in theory) with each run of the same software. But it is also
possible that your environment contains different XSLT processors (or
versions of the same processor) and/or different serializers.

 

[Richard Tobin]

Using xalan 2.7.1 on Tomcat 5.5 & Weblogic 9.2 but I get different
results even though the same web app is deployed to each. The trouble
is the following xslt produces "<xsl:" tags on WL but "<xslt:" tags
(which is what I would expect!) on tomcat

Why do you care? The choice of prefix should not matter - at least in
this case. It is rather surprising though, and prefixes can be important
when generating something like a stylesheet, because of the presence
of prefixes in attributes (and possibly text).

also noticed the
<stylesheet> attributes are generated in different orders also!

The order doesn't matter, and there's no reason for them to be in the
same order.

-- Richard

 

[David Carlisle]

Can anyone shed some light on this? this is totally bizarre, how can
the same code produce different results? - is there something
different picked up from the environment perhaps? also noticed the
<stylesheet> attributes are generated in different orders also!

thanks in advance

harry

As others have said it shouldn't matter (but might anyway) which prefix
is used. The XSLT 1.0 spec was not particularly clear which was the
"expected" prefix when namespace-alias is used. (And in fact is explict
that a system was always free to arbitrarily choose prefixes).
XSLT 1.0 processors differ in which one they choose.

XSLT2 tightens this up and makes it explicit which prefix will result,
but both the systems you used were 1.0 systems.

David

 

[harryajh]

As others have said it shouldn't matter (but might anyway) which prefix
is used. The XSLT 1.0 spec was not particularly clear which was the
"expected" prefix when namespace-alias is used. (And in fact is explict
that a system was always free to arbitrarily choose prefixes).
XSLT 1.0 processors differ in which one they choose.

XSLT2 tightens this up and makes it explicit which prefix will result,
but both the systems you used were 1.0 systems.

David

--http://dpcarlisle.blogspot.com

thanks for all the replies, the reason I need them to be consistant is
because other sections of xslt code are added (please don't ask why as
it will take ages to explain!) to the final document, these have fixed
tags - so my code will only run on one of the app servers as they
generate different tags!

 

[Joseph Kesselman]

Xalan tried, but didn't promise, to produce "the expected prefixes" as a
courtesy to the users.

 

[A. Bolmarcich]

As others have said it shouldn't matter (but might anyway) which prefix
is used. The XSLT 1.0 spec was not particularly clear which was the
"expected" prefix when namespace-alias is used. (And in fact is explict
that a system was always free to arbitrarily choose prefixes).
XSLT 1.0 processors differ in which one they choose.

XSLT2 tightens this up and makes it explicit which prefix will result,
but both the systems you used were 1.0 systems.

Where is this stated in the XSLT2 specification?

An example of namespace-alias in

http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-namespace-alias

contains: "Note that an implementation may output different namespace
prefixes from those appearing in this example".

 

[David Carlisle]

Where is this stated in the XSLT2 specification?

An example of namespace-alias in

http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-namespace-alias

contains: "Note that an implementation may output different namespace
prefixes from those appearing in this example".

The rules in the section you quote, or as rephrased in teh note at the
end of that section, just before the example.


These rules achieve the effect that the element generated from the
literal result element will have an in-scope namespace node that binds
the result-prefix to the target namespace URI, provided that the
namespace declaration associating this prefix with this URI is in scope
for both the xsl:namespace-alias instruction and for the literal result
element. Conversely, the stylesheet-prefix and the literal namespace URI
will not normally appear in the result tree.

so this makes it clear that the stylesheet-prefix won't be the one used
in the result tree (unless that prefix is added to teh result tree
anyway by different means)

the difference between xpath1 and 2 here is that in xpath 1 models
qnames such that just the uri matters so it can't make any normative
statements about preserving prefixes, but xpath2 models qnames as
triples of prefix local name and uri, so can model preserving prefixes.


David

 

[harryajh]

The rules in the section you quote, or as rephrased in teh note at the
end of that section, just before the example.

These rules achieve the effect that the element generated from the
literal result element will have an in-scope namespace node that binds
the result-prefix to the target namespace URI, provided that the
namespace declaration associating this prefix with this URI is in scope
for both the xsl:namespace-alias instruction and for the literal result
element. Conversely, the stylesheet-prefix and the literal namespace URI
will not normally appear in the result tree.

so this makes it clear that the stylesheet-prefix won't be the one used
in the result tree (unless that prefix is added to teh result tree
anyway by different means)

the difference between xpath1 and 2 here is that in xpath 1 models
qnames such that just the uri matters so it can't make any normative
statements about preserving prefixes, but xpath2 models qnames as
triples of prefix local name and uri, so can model preserving prefixes.

David

--http://dpcarlisle.blogspot.com

thanks again for all the replies, looks like it will only work on one
server then - still very surprised though that the same XSLT processor
(checked & no others are within the entire bea & tomcat directory
structures!) can produce different results like this!