Idententity Transform & Default namespace

Discussion in 'XML' started by Bilal, Sep 28, 2006.

  1. Bilal

    Bilal Guest

    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.

    *** Sent via Developersdex http://www.developersdex.com ***
     
    Bilal, Sep 28, 2006
    #1
    1. Advertising

  2. 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.


    --

    Martin Honnen
    http://JavaScript.FAQTs.com/
     
    Martin Honnen, Sep 28, 2006
    #2
    1. Advertising

  3. Bilal wrote:
    > 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.

    --
    () ASCII Ribbon Campaign | Joe Kesselman
    /\ Stamp out HTML e-mail! | System architexture and kinetic poetry
     
    Joe Kesselman, Sep 28, 2006
    #3
  4. Bilal

    Bilal Guest

    Martin Honnen wrote:

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

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


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

    <message xmlns="someNS">


    >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.

    *** Sent via Developersdex http://www.developersdex.com ***
     
    Bilal, Sep 28, 2006
    #4
  5. Bilal

    Bilal Guest

    Joe Kesselman wrote:

    >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.

    *** Sent via Developersdex http://www.developersdex.com ***
     
    Bilal, Sep 28, 2006
    #5
  6. > 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.



    "Bilal" <> wrote in message
    news:451b8790$0$25781$...
    > 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.
    >
    > *** Sent via Developersdex http://www.developersdex.com ***
     
    Dimitre Novatchev, Sep 29, 2006
    #6
  7. Bilal

    George Bina Guest

    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 Cristian Bina
    <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
    http://www.oxygenxml.com
     
    George Bina, Sep 29, 2006
    #7
  8. Bilal

    George Bina Guest

    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 Cristian Bina
    <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
    http://www.oxygenxml.com
     
    George Bina, Sep 29, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Èý¹â
    Replies:
    1
    Views:
    599
    William F. Robertson, Jr.
    Jul 29, 2003
  2. Replies:
    0
    Views:
    5,167
  3. Anonymous
    Replies:
    3
    Views:
    560
    Ron Natalie
    Aug 18, 2003
  4. Jason Heyes
    Replies:
    1
    Views:
    468
    Woebegone
    Nov 19, 2004
  5. Max
    Replies:
    2
    Views:
    515
    Joe Kesselman
    Aug 1, 2006
Loading...

Share This Page