W3C home > Mailing lists > Public > public-xmlsec@w3.org > December 2010

RE: XPath grammar

From: Pratik Datta <pratik.datta@oracle.com>
Date: Sat, 4 Dec 2010 22:38:43 -0800 (PST)
Message-ID: <544078cc-5e90-4363-b849-d23085c76590@default>
To: Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>, XMLSec WG Public List <public-xmlsec@w3.org>

This subset that you have proposed is far more restrictive that the subset that we already have. That makes is not very useful, many of the examples that are currently put in are not allowed by your grammar any more. I see no reason for removing all the arithmetic operators, relational operators, functions, variable references, etc. They do not affect streamability.

I was intending this XPath subset to be reusable for other streaming applications too.   Because when it comes to implementation it will be very unlikely that anybody will create a separate XPath implementation just for XML signature. Rather I expect people will create a single streaming XPath implementation and use it for many things. So it is better if do not put in the IncludedXPath and ExcludedXPath contructs into the XPath subset, rather we put this in as an additional limitation imposed by the C14N 2.0 data model, which cannot accept attributes without their owner elements..  Similarly we shouldn't distinguish between final and non final steps. Basically I am saying that we should go with your option c).


-----Original Message-----
From: Meiko Jensen [mailto:Meiko.Jensen@ruhr-uni-bochum.de] 
Sent: Friday, December 03, 2010 6:34 AM
To: XMLSec WG Public List
Subject: XPath grammar

I just tried to create the BNF grammar of the streamable XPath subset as specified during the F2F meeting. Please review carefully, since I'm not convinced I got it right, and especially since I was rather restrictive on what I allowed to be used within the predicates. I think there would be several spots where additional operators or functions might be useful, but I didn't see the grammar getting easier, hence decided to cut them off anyway.

Also, I decided to do two separate grammars, one for IncludedXPath and one for ExcludedXPath. The problem of merging both into one grammar is that this would require most of the tokens to be relabeled to "IncludedXPathFoo" and "ExcludedXPathFoo", which I already found annoying for the "FinalStepFoo" and "NonFinalStepFoo" tokens.

After all, I'm not happy with that solution either, since the only difference between IncludedXPath and ExcludedXPath grammar is the "attribute" AxisName being allowed in the latter only. Hence, we have three options here:

a) merge Included and Excluded into one grammar
b) leave as is
c) simplify the grammar even more, stating the intended differences between Included and Excluded, or non-final step and final step, respectively, as textual comments for each definition (as done in the spec document by now).

However, this should close my Action-687, Action-688, and Action-690 for now.

best regards


Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security
Horst Görtz Institute for IT-Security
Ruhr University Bochum, Germany
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de
Received on Sunday, 5 December 2010 06:40:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:15 UTC