- 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