Idententity Transform & Default namespace

[Bilal]

Hello all,
I came across this problem while working out the bugs in my identity
trasnformation stylesheets but sidestepped it for later to see if there
is an easier/better solution. This is essentially following up to my
last post so apologies for repeating parts of the post.

The transformation stylesheet is (after corrections from kind
contributors

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/message/Control/Trace/Id">
<xsl:copy>
<!-- use that if you have other attributes to copy -->
<xsl:apply-templates select="@*"/>
<xsl:attribute name="extension">bbb-999</xsl:attribute>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

which puts/adds a new value to the
"/message/Control/Trace/Id/@extension" attribute and the xml to be
transformed is:

<?xml xmlns="someNS" version="1.0" encoding="ISO-8859-1"?>
<message>
<id>Text</id>
<creationTime>Text</creationTime>
<versionCode/>
<Id>Text</Id>
<processingCode/>
<processingModeCode/>
<acceptCode/>
<commRcv>
<device>
<id extension="Old_Ext">Text</id>
</device>
</commRcv>
<commSnd>
<device>
<id>Text</id>
</device>
</commSnd>
<Control>
<author>
<Entity>
<id>Text</id>
<code/>
<Organization>
<id>Text</id>
</Organization>
</Entity>
</author>
<Trace>
<Id extension="OLD">Text</Id>
<person>
<value/>
<Text>String</Text>
</person>
<birthTime>
<value>Text</value>
<Text>String</Text>
</birthTime>
<name>
<value>Text</value>
<Text>String</Text>
</name>
</Trace>
</Control>
</message>

The issue is that the 'data' XML actually defines a default namespace,
as I have now indicated, which I had removed to ease troubleshooting the
stylesheet (and in my previous postings). The stylesheet obviously works
if e.g. by declaring xmlns:dns="someNS" and using the xpath
"/dns:message/dns:Control/dns:Trace/dns:Id/@extension" instead. However
this approach is cumbersome because I have to then mess with the
original "plain" xpath by adding in the prefix etc. and rather avoid
that if I can.

So is there some other way to add the attribute during transformation
WITHOUT using the namespace-qualified Xpath? A trivial solution would be
to remove the default NS declaration from the data XML before
processing, transform it, and then add the default NS during a
subsequent transformation. From what I understand of the specs, I
believe the last 'step' is a NO NO and the transformation engine is
supposed to either not perform the action or return an error.

Is there a better way to do this then? Just for curiosity, why is the
modified Xpath required for the transformation whereas apps like XMLSpy
do evaluate the "plain" Xpath fine?

Regards,

Bilal B.

 

[Martin Honnen]

Bilal wrote:

<?xml xmlns="someNS" version="1.0" encoding="ISO-8859-1"?>

^^^^^^^^^^^^^^
That is nonsense, a namespace declaration in the XML declaration.

The issue is that the 'data' XML actually defines a default namespace,
as I have now indicated, which I had removed to ease troubleshooting the
stylesheet (and in my previous postings). The stylesheet obviously works
if e.g. by declaring xmlns:dns="someNS" and using the xpath
"/dns:message/dns:Control/dns:Trace/dns:Id/@extension" instead. However
this approach is cumbersome because I have to then mess with the
original "plain" xpath by adding in the prefix etc. and rather avoid
that if I can.

So is there some other way to add the attribute during transformation
WITHOUT using the namespace-qualified Xpath?

Yes, but using the prefix is easier. Otherwise you need e.g.
<xsl:template match="/*[local-name() = 'message' and namespace-uri()
= 'someNS']/*[local-name() = 'Control' and namespace-uri() =
'someNS']/*[local-name() = 'Trace' and namespace-uri() =
'someNS']/*[local-name() = 'Id' and namespace-uri() = 'someNS']">

A trivial solution would be
to remove the default NS declaration from the data XML before
processing, transform it, and then add the default NS during a
subsequent transformation. From what I understand of the specs, I
believe the last 'step' is a NO NO and the transformation engine is
supposed to either not perform the action or return an error.

It is possible to write stylesheets that strip namespace (approach e.g.

<xsl:template match="*">
<xsl:element name="{local-name()}" namespace="">
<xsl:apply-templates select="@* | node()"/>
</xsl:element>
</xsl:template>

)and it is possible to write one that adds or changes namespaces
(approach e.g.

<xsl:template match="*">
<xsl:element name="{local-name()}"
namespace="http://example.com/2006/ex1">
<xsl:apply-templates select="@* | node()"/>
</xsl:element>
</xsl:template>

) so I am not sure what part of what spec you are referring to.

Just for curiosity, why is the
modified Xpath required for the transformation whereas apps like XMLSpy
do evaluate the "plain" Xpath fine?

Ask that question in an XMLSpy forum/support group.

 

[Joe Kesselman]

So is there some other way to add the attribute during transformation
WITHOUT using the namespace-qualified Xpath?

Not in XPath 1.0/XSLT 1.0. The 2.0 version of those specs adds the
concept of being able to specify a default namespace for the XPaths, but
2.0 is still not officially approved (though I believe it's in Candidate
Recommendation status, so it's getting close) and support for it is
still rare.

As others have said: Use properly qualified names in your XPaths. Or do
some moderately obscene things with predicates, but those are generally
desirable only as special-case solutions for particular problems.

apps like XMLSpy do evaluate the "plain" Xpath fine?

If so, XMLSpy is violating the Recommendations, badly, and should be
discarded until it has been fixed. The only way we get reliably
interoperable standards is by demanding that software honor those standards.

 

[Bilal]

^^^^^^^^^^^^^^
That is nonsense, a namespace declaration in the XML declaration.

Mea culpa; edited the wrong line! I meant to say:

Yes, but using the prefix is easier. Otherwise you need e.g.

Ouch, those predicates are nasty!

It is possible to write stylesheets that strip namespace
(approach e.g. [templates deleted]) so I am not sure what
part of what spec you are referring to.

Thanks for the sample templates! Looks like stripping and re-adding the
namespace might be an option.
Hmm... now come to think of it, I can't recall. Maybe, I dreamt it up

Ask that question in an XMLSpy forum/support group.

Fair enough!

Regards,

Bilal B.

 

[Bilal]

As others have said: Use properly qualified names in your
XPaths. Or do some moderately obscene things with predicates,
but those are generally desirable only as special-case
solutions for particular problems.

Based on the response, I guess I'll avoid the 'shortcut' by
stripping/adding the default namespace and instead use fully qualified
names.

If so, XMLSpy is violating the Recommendations, badly, and
should be discarded until it has been fixed. The only way
we get reliably interoperable standards is by demanding
that software honor those standards.

I agree with your opinion though dumping XMLSpy might not be an option
for many (novice/intermediate) users out there; I'll query XMLspy's
publisher about that aspect and see what they have to say.

Thanks again for the sugestions!

Regards,

Bilal B.

 

[Dimitre Novatchev]

Just for curiosity, why is the

modified Xpath required for the transformation whereas apps like XMLSpy
do evaluate the "plain" Xpath fine?

Such applications are called non-compliant.

Anyone, who really wants to use XSLT should only use compliant XSLT
processors.


Cheers,
Dimitre Novatchev.

 

[George Bina]

Hi,

It may not be a non conformant behavior from an XPath 2.0 evaluator. It
all depends on the namespace context and the xpath default namespace
that the XPath 2.0 evaluator uses.
In oXygen's case for instance we allow the user to specify how the
xpath default namespace should be set when evaluating an XPath 2.0
expression, it can be a specific namespace, no namespace or the
namespace of the root element (always or only if the root element is in
the default namespace):
http://www.oxygenxml.com/doc/ug-standalone/preferences-xpath.html
In case the xpath default namespace from the XPath 2.0 evaluator
context is the same as the document default namespace then XPath 2.0
expressions without prefixes for name tests will match elements or
attributes names from the document default namespace.

Best Regards,
George

 

[George Bina]

Hi,

It may not be a non conformant behavior from an XPath 2.0 evaluator. It
all depends on the namespace context and the xpath default namespace
that the XPath 2.0 evaluator uses.
In oXygen's case for instance we allow the user to specify how the
xpath default namespace should be set when evaluating an XPath 2.0
expression, it can be a specific namespace, no namespace or the
namespace of the root element (always or only if the root element is in
the default namespace):
http://www.oxygenxml.com/doc/ug-standalone/preferences-xpath.html
In case the xpath default namespace from the XPath 2.0 evaluator
context is the same as the document default namespace then XPath 2.0
expressions without prefixes for name tests will match elements or
attributes names from the document default namespace.

Best Regards,
George