RE: Re: Re: XPath Expression

Thanks John,

(//. | //@* | //namespace::*)[not (self::attribute and (name()="URI") and

looks great and your explanations were excellent.  I knew that my node()
and NodeType() functions weren't valid but didn't know what the valid replacements

Though this was mainly an academic exercise, I think it has helped a number
of much better understand the potential of XPath transforms in XML Signatures.

One more question, is node() in XPath supposed to match attributes?  When
I read XPath, it seems like it should but my experience with XSLT makes
it seem like node() matches all node types but attributes.  

Hi Ed, 

Part of the problem with the exercise is that it really depends on how the
<Reference> element was obtained in the first place.  Do we want to omit
the URI attribute of every Reference element, or a particular Reference

Moreover, in the context of dsig, it is already known that you can't apply
an XPath transform to the SignedInfo anyway.  The question Blake originally
asked sounds exactly like the type of thing I've been wanting to do for
some time now, which is to have the ability to vary where signed information
comes from without breaking the signature.  Having the ability to apply
XPath to SignedInfo (with some caveats) is one clean way of doing that.
 The mail archives have lots of comments from me on this issue, along with
repeated statements from the WG that the method is too scary.  So, the short
answer is that 'it can't be done'.

From the purely academic standpoint, i.e. supposing it could be done AND
supposing that XPath transforms returned a node-set result from a whole
tree rather than returning a boolean for each node AND supposing that you
wanted to get rid of every URI attribute from every Reference, the following
should do the trick:

(//. | //@* | //namespace::*)[not (self::attribute and (name()="URI") and

This is similar to your prior expression with the following exceptions.

1) I replaced node() with (//. | //@* | //namespace::*) because we want
to descend to all element nodes (// is for descendant-or-self::node) plus
all attribute and namespace nodes (//@* means all attributes of all nodes
obtained by //., and //namespace::* means all namespace nodes of all elements).

2) I replaced NodeType(attribute) with self::attribute.  NodeType is a non-terminal
symbol in the XPath grammar, not a function that can be called.  However,
it is the right idea to make sure the node we want to reject is actually
an attribute.  The prior expressions would've also thrown out child elements
of Reference if they were named URI.

If you want to get rid of a URI for a specific Reference element, then it
is necessary to figure out how to identify that Reference element, then
replace parent::dsig:Reference in the expression above.  For example, if
you identified the reference with an ID attribute having the value 'foo',
then the replacement would be parent::dsig:Reference[id('foo')].

John Boyer 
Senior Product Architect, Software Development 
Internet Commerce System (ICS) Team 
PureEdge Solutions Inc. 
Trusted Digital Relationships 
v: 250-708-8047  f: 250-708-8010 
1-888-517-2675 <>    


-----Original Message----- 
From: [] 
Sent: Thursday, August 02, 2001 9:43 AM 
To: merlin 
Subject: Re: Re: Re: XPath Expression 

I think if XPath could be used to return a nodeset that excludes certain

attribute nodes, then what you have suggested would fit in.  I remain curious,

as an academic exercise, as to whether there exists such a single XPath

expression.  Perhaps something like 

"node()[not (NodeType(attribute) and (name()="URI") and parent::dsig:Reference)]"

is getting closer. 


-- Original Message -- 

>Hi Ed, 
>>I'd certainly be keen to see the full working XPath expression if someone

>>wants to take up the challenge.  Merlin's suggestion, by itself, is not

>>the whole solution but only part as it returns a boolean, not nodes. 

>Blake asked for something to put in an XPath transform; 
>our XPath transform does a boolean test of each node in 
>the node set against its expression. 
>So, you are right; what I suggested is not a general 
>XPath expression for selecting all of a document but 
>its URI attributes; XSLT is the tool for that job. 
>But, it is a suitable test expression for our XPath 
>transform to perform this task. 
>I think. (sometimes) 
>>In general, XPath is good at selecting nodes but was not really intended

>>for removing subnodes.  With current tools, I'd say removing subnodes

>>best done with XSLT. 
>>BTW, the XSLT I've presented below does actually do the trick. 
>>-- Original Message -- 
>>>I'd guess that something like not ((name() =3D "URI") and parent::dsig:R=

>>>might work. 
>>>>>>This would allow me to change the URI without altering the validity

>>>>>If it's being used in the Canonical XML context, remove the '//@*'

>>>>>         (//. | //@* | //namespace::*) 
>>>>Correct me if I'm wrong but wouldn't the above remove ALL attributes,

>>>>just the one Blake wants removed. 
>>>>I'm not sure that there is an XPath solution but the solution in XSLT

>>>>look like this: 
>>>><?xml version=3D"1.0" encoding=3D"UTF-8"?> 
>>>><xsl:stylesheet version=3D"1.0" 
>>>>  xmlns:xsl =3D"" 
>>>>  xmlns:xmlsig=3D""> 
>>>><!-- Identity transform --> 
>>>><xsl:template match=3D"@*|node()"> 
>>>>  <xsl:copy> 
>>>>    <xsl:apply-templates select=3D"@*|node()"/> 
>>>>  </xsl:copy> 
>>>><!-- Skip the Reference/@URI attribute --> 
>>>><xsl:template match=3D"xmlsig:Reference/@URI" priority=3D"2"/> 
>>Ed Simon 
>>XMLsec Inc. 
>>Interested in XML Security Training and Consulting services?  Visit "www.=


>Baltimore Technologies plc will not be liable for direct,  special,  indirect

>or consequential  damages  arising  from  alteration of  the contents of

>message by a third party or as a result of any virus being passed on. 
>In addition, certain Marketing collateral may be added from time to time

>promote Baltimore Technologies products, services, Global e-Security or

>appearance at trade shows and conferences. 
>This footnote confirms that this email message has been swept by 
>Baltimore MIMEsweeper for Content Security threats, including 
>computer viruses. 


Ed Simon 
XMLsec Inc. 

Interested in XML Security Training and Consulting services?  Visit "".

Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "".

Received on Thursday, 2 August 2001 14:11:40 UTC