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 |