- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Thu, 28 Oct 2010 00:00:16 -0700 (PDT)
- To: public-xmlsec@w3.org
I realized we have another open issue with the id() function. Currently we are only allowing functions inside predicates. However the id() function is different from the other functions, it doesn't return a string value or an integer value, instead it return a nodeset. So it cannot be used like this //chapter[id("i1")] This will NOT return the chapter that has an id of "i1". The id function will return a nodeset containing all nodes that have an id of "i1", which will usually be only one node. this nodeset will be converted to a boolean. True if there is at least one node in the nodeset, false otherwise. If it is true then all <chapter> elements will be returned and if false then no chapter elements will be returned. Instead we need to use it like this id("i1") This will return the element with id "i1" or like this id("i1")/self::chapter This will return the element with id "i1" if it is a chapter element However we do not currently allow this kind of syntax, we deliberately removed the FilterExpr, as it gets really complicated, I don't want to add it back just for id(), because then we have to also support many other complicated expressions. Other Updates to XPath profile http://www.w3.org/2008/xmlsec/Drafts/xmldsig-xpath/ Oct 27th edition * ACTION-667 Add text regarding potential 1-pass issues to XPath document Added as new section 2.1 Limitations with one-pass streaming However I changed the last sentence it was "In general, applications SHOULD avoid backward references of any kind if they want to use streaming-based processing of the XML Signature." Modified it to "These problems can be alleviated by doing the verification in two passes, the first pass merely scanning the document for the <Signature> and the second pass actually evaluating the XPath , canonicalizing and computing the digest. Applications that require pure one pass processing should avoid backward references of any kind." * ACTION-677 Remove .. from XPath subset Removed it * ACTION-678 Add editorial warning about potential future changes to XPath subset Did not add this. If we are planning going to last call, this would look odd. Another issue, is whether we should give a name to this XPath profile, so that people can refer to different profiles by name. Pratik
Received on Thursday, 28 October 2010 07:02:30 UTC