W3C home > Mailing lists > Public > public-xmlsec@w3.org > October 2009

Re: WS-Fragment: Another XPath subset

From: <pratik.datta@oracle.com>
Date: Mon, 19 Oct 2009 09:55:59 -0700
Message-ID: <4ADC9A1F.2060307@oracle.com>
To: Scott Cantor <cantor.2@osu.edu>
CC: "'Frederick Hirsch'" <frederick.hirsch@nokia.com>, edsimon@xmlsec.com, "'Thomas Roessler'" <tlr@w3.org>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>, "'Yves Lafon'" <ylafon@w3.org>
I have been thinking that maybe we should define multiple subsets in 
order of complexity, with one subset strictly including the previous 
one.  Similar to how WS-Fragment has three levels - QName only, XPath 
Level 1, full Xpath.


On 10/16/2009 7:41 AM, Scott Cantor wrote:
> Frederick Hirsch wrote on 2009-10-16:
>> I'm not sure I understand the harm of more than one profile of an
>> existing specification for different purposes. The core XPath spec is
>> defined and use of a profile need not be that confusing.
> Well, profiling is done for different reasons. One such reason is so that
> people can implement only subsets. The problem with multiple profiles is
> that you can't reuse those subset implementations.
>> I agree it makes sense for XML Security WG to define a profile as part
>> of its work to be sure it is appropriate for security application.
> I think it's important that we make this extensible so that we can leave
> that part of the standard agile enough to change, and we all agreed to that
> idea.
>>> Overall there is difference is motivations - The Dsig Xpath subset
>>> is designed with the constraints of a streaming parser. Code
>>> complexity is not issue - it just needs to be efficient in time and
>>> memory usage. Whereas the WS Fragment XPath subset is designed to
>>> reduce code complexity. However I think WS-Fragment can also benefit
>>> from streaming.
> I have to disagree with this one. I think code complexity is a huge problem,
> and I favor that requirement at least as much as streaming is.
> -- Scott
Received on Monday, 19 October 2009 16:57:29 UTC

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