|
Subject: Re: [xsl] Why doesn't this simple XSLT (Identity transform) work? From: <ohaya@xxxxxxx> Date: Tue, 1 Dec 2009 21:46:05 -0500 |
Hi Ken,
Thanks, not just for the solution, but for the VERY detailed explanation. I know that I'll have to re-re-read your post, probably several more times, but if I'm understanding, basically the problem was that the match I was using was not matching anything, so that xsl:template was not "catching", and the reason for not matching was because of the namespace.
Is that right?
Thanks again,
Jim
---- "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
> At 2009-12-01 19:43 -0500, ohaya@xxxxxxx wrote:
> >It's been awhile since I've worked with XSLT, but I'm having to
> >implement one that removes an element (<Signature>) from the
> >incoming (SOAP) message.
>
> Actually, you want to remove the element:
>
> {http://www.w3.org/2000/09/xmldsig#}Signature
>
> ... regardless of the prefix used in the syntax of the input XML.
>
> >I know that this should be simple, and I know that I have written
> >similar XSLT before, but for some reason, I can get this to work.
>
> You are forgetting that XSLT matches on the expanded name of a node
> and not the specified name of the node. Prefixes are irrelevant
> (other than playing the role of associating the namespace URI string
> for the expanded name).
>
> >Here's an example SOAP message:
> >...
> >And, here's the XSLT that I'm using:
> >...
>
> Thank you for providing the plug-and-play.
>
> >What the XSLT seems to be doing is just doing the Identity
> >transform, and copying everything from the input message to the
> >output, i.e., the "<xsl:template match="//Signature">" is not
> >getting processed at all.
>
> Right. And, BTW, the "//" isn't needed, but that isn't what is wrong.
>
> >I've tried different things for that template match, including just
> >"Signature", a "fully-qualified" match term, etc.
>
> You didn't try a qualified name match. A qualified name has as its
> lexical space the specified name for the element and as its value
> space the expanded name for the element. Two qualified names are
> compared by their expanded names. A qualified name is exposed and
> written using the specified name and the in-scope namespaces for the
> prefix used or not by the specified name.
>
> >I have the impression that the XSLT processing should always use the
> >more specific match (i.e., the one above, and not the Identity
> >transform), but it doesn't seem to be working :(...
>
> That isn't true in general but happens to be true in this case, you
> just haven't named the element properly.
>
> Some of the detail relevant to your situation is that every match
> pattern that is more complex than a simple name has the same inferred
> priority of 0.5, without any kind of "increasing level of complexity
> based on length", just 0.5 full stop. A simple name has the inferred
> priority of 0. A wild card has the inferred priority of
> -0.5. (There are a couple others not in play here) Since all of
> your template rules that match the Signature element have different
> priorities, the one that is highest (the simple name) trumps the
> lower one (the element wild card).
>
> >I'm sure that I am missing something really obvious here,
>
> The qualified element name in your XSLT has to match the qualified
> element name in the XML (in the value space, not in the lexical
> space, thus the expanded names must be equal).
>
> The specified element name in your XSLT has no relation to the
> specified element name in the XML (the lexical space).
>
> I hope the solution below illustrates this for you.
>
> . . . . . . . . . . Ken
>
> t:\ftemp>type ohaya.xml
> <SOAP:Envelope xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
> xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
> xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP:Header>
> <wsse:Security SOAP:mustUnderstand="1">
> <saml:Assertion MajorVersion="1" MinorVersion="1"
> AssertionID="ID46a342be-9d3a-437a-8a26-85fcd72a723d"
> Issuer="http://foo.com" IssueInstant="2009-12-01T21:55:13Z">
> <saml:Conditions NotBefore="2009-12-01T21:54:58Z"
> NotOnOrAfter="2009-12-01T22:10:28Z"/>
> <saml:AuthenticationStatement
> AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"
> AuthenticationInstant="2009-12-01T21:55:13Z">
> .....
> </saml:AuthenticationStatement>
> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
> ...
> </Signature></saml:Assertion></wsse:Security>
> </SOAP:Header>
> <env:Body>
> <m:hello xmlns:m="http://services">
> <m:x>123</m:x></m:hello>
> </env:Body>
> </SOAP:Envelope>
>
> t:\ftemp>call xslt ohaya.xml ohaya.xsl
> <?xml version="1.0" encoding="utf-8"?><SOAP:Envelope
> xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
> xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
> <SOAP:Header>
> <wsse:Security SOAP:mustUnderstand="1">
> <saml:Assertion MajorVersion="1" MinorVersion="1"
> AssertionID="ID46a342be-9d3a-437a-8a26-85fcd72a723d"
> Issuer="http://foo.com" IssueInstant="2009-12-01T21:55:13Z">
> <saml:Conditions NotBefore="2009-12-01T21:54:58Z"
> NotOnOrAfter="2009-12-01T22:10:28Z"/>
> <saml:AuthenticationStatement
> AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"
> AuthenticationInstant="2009-12-01T21:55:13Z">
> .....
> </saml:AuthenticationStatement>
> </saml:Assertion></wsse:Security>
> </SOAP:Header>
> <env:Body>
> <m:hello xmlns:m="http://services">
> <m:x>123</m:x></m:hello>
> </env:Body>
> </SOAP:Envelope>
> t:\ftemp>type ohaya.xsl
> <?xml version="1.0" encoding="utf-8"?>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:dp="http://www.datapower.com/extensions"
> xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
> xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:sig="http://www.w3.org/2000/09/xmldsig#"
> >
> <xsl:output method="xml"/>
>
> <xsl:template match="node()|@*">
> <xsl:copy>
> <xsl:apply-templates select="node()|@*"/>
> </xsl:copy>
> </xsl:template>
>
> <xsl:template match="sig:Signature">
> </xsl:template>
>
> </xsl:stylesheet>
>
> t:\ftemp>rem Done!
>
>
>
> --
> Vote for your XML training: http://www.CraneSoftwrights.com/s/i/
> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
> Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
> Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
> G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
> Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
> Legal business disclaimers: http://www.CraneSoftwrights.com/legal
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| Re: [xsl] Why doesn't this simple X, G. Ken Holman | Thread | Re: [xsl] Why doesn't this simple X, ohaya |
| Re: [xsl] Why doesn't this simple X, G. Ken Holman | Date | Re: [xsl] Why doesn't this simple X, ohaya |
| Month |