- 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 UTC