W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > August 2009

7235 - additional text for the proposal

From: Doug Davis <dug@us.ibm.com>
Date: Tue, 25 Aug 2009 15:27:41 -0400
To: public-ws-resource-access@w3.org
Message-ID: <OF98D75971.4EFEC6E8-ON8525761D.006A28CD-8525761D.006AED95@us.ibm.com>
I think this issue is a bit broader than I initially thought.  One of the 
main reasons why using the XPath URI is problematic is because we're not 
_just_ saying "use xpath".  We're also telling people how to use it.  For 
example, right now it means to filter over the event data (in 
ws-eventing).  But in the member submission it used to mean filter over 
the entire envelope.  This additional bit of information is not part of 
the xpath spec and can only be inferred by something outside of the xpath 
spec.  Now, WS-Eventing's Dialect element itself can't mandate this type 
of information since different dialects may choose to filter over 
different bits of data.  So, aside from changing the URI to something that 
we own we should also consider adding the following text to the Dialect 
definition:

current text:
[Body]/wse:Subscribe/wse:Filter/@Dialect
    Implied value is "http://www.w3.org/TR/1999/REC-xpath-19991116".
    While an XPath predicate expression provides great flexibility and 
power, alternate filter dialects may be defined. For instance, a simpler, 
less powerful dialect might be defined for resource-constrained 
implementations, or a new dialect might be defined to support filtering 
based on data not included in the notification message itself. If desired, 
a filter dialect could allow the definition of a composite filter that 
contained multiple filters from other dialects. 

new text (in ***)
[Body]/wse:Subscribe/wse:Filter/@Dialect
    Implied value is "http://www.w3.org/TR/1999/REC-xpath-19991116".
    While an XPath predicate expression provides great flexibility and 
power, alternate filter dialects may be defined. For instance, a simpler, 
less powerful dialect might be defined for resource-constrained 
implementations, or a new dialect might be defined to support filtering 
based on data not included in the notification message itself. If desired, 
a filter dialect could allow the definition of a composite filter that 
contained multiple filters from other dialects.  *** New dialect 
definitions MUST include sufficient information for proper application. 
For example, it would need to include the context (which data) over which 
the filter operates.  ***

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Received on Tuesday, 25 August 2009 19:28:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:09 GMT