RE: context node for XPath filter dialect ambiguous?

This is issue 8323 http://www.w3.org/Bugs/Public/show_bug.cgi?id=8323.



A possible way to address this issue is to add the highlighted sentence in [1] to WS-Eventing specification. How does this sound to you?



Thanks.



[1]


[Body] /wse:Subscribe/wse:Filter/@Dialect
Implied value is  "http://www.w3.org/2009/09/ws-evt/Dialects/XPath10".

XPath expressions provided for the event filtering should take into account the notification format (wrapped or unwrapped). 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



-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Johannes Echterhoff
Sent: Tuesday, December 01, 2009 10:48 AM
To: public-ws-resource-access@w3.org
Subject: AW: context node for XPath filter dialect ambiguous?



Hi again.



It seems like it is the responsibility of the subscriber to know which type or types of event XML it is subscribing for. As WS-Eventing does not add a wrapper around notifications by itself, it can only be the events that the client subscribes to which come in multiple formats - which the subscriber should know and then write the Xpath expression accordingly (or rather, avoid different event XML types in one subscription altogether if Xpath [1.0] based filtering should be used).



So that would solve the issue with the wrapper format for me (second half of my previous email).



Now the only thing that would be good to clarify in the WS-Eventing specification is how an Xpath expression should be created if the context node is the root node of the event XML - this would best be done with an example and some expressions which do or do not result in a match.



Best regards,

Johannes Echterhoff





> -----Ursprüngliche Nachricht-----

> Von: public-ws-resource-access-request@w3.org

> [mailto:public-ws-resource- access-request@w3.org] Im Auftrag von

> Johannes Echterhoff

> Gesendet: Freitag, 13. November 2009 10:54

> An: public-ws-resource-access@w3.org

> Betreff: context node for XPath filter dialect ambiguous?

>

> Hi.

>

> Reading the latest draft of WS-Eventing, I was wondering what the

> context node for an Xpath 1.0 filter really is. The specification says

> that the context node is "the root of the event XML". Maybe its just

> me but does

this

> mean the root node of the document where the event XML is contained or

> the top element of the event XML (which one could also call 'root of

> the event XML').

>

> Suppose I have got the following event XML:

>

> <swes:SWESEvent xmlns:swes="http://www.opengis.net/swes/1.0"

> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

> xmlns:wsa="http://www.w3.org/2005/08/addressing">

>   <swes:identifier

> codeSpace="http://www.example.org">a87s9c76s</swes:identifier>

>   <swes:code>CAPABILITIES_CHANGED</swes:code>

>   <swes:service>

>     <wsa:Address>http://my.swe-service.com/path</wsa:Address<http://my.swe-service.com/path%3c/wsa:Address>>

>   </swes:service>

> </swes:SWESEvent>

>

> Now I want to filter via Xpath to get all events with codeSpace

> "http://www.opengis.net/swes/1.0#EventCode" and value

"CAPBILITIES_CHANGED".

>

> Let us consider the following Xpath expressions:

>

> 1. swes:SWESEvent/swes:code='CAPABILITIES_CHANGED'

> 2. /swes:SWESEvent/swes:code='CAPABILITIES_CHANGED'

> 3. swes:code='CAPABILITIES_CHANGED'

>

> I evaluated the expressions with different choice of context node:

> - with context node root node: 1+2 are true ... 3 is false

> - with context node swes:SWESEvent: 1 is false ... 2+3 are true

>

> -----------

>

> What would happen if the event XML is somehow wrapped already before

> the Xpath is applied - or is that not allowed / considered?

>

> Example:

>

> <abc:Wrapper xmlns:swes="http://www.opengis.net/swes/1.0"

> xmlns:abc="http://www.example.org"

> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

> xmlns:wsa="http://www.w3.org/2005/08/addressing">

>   <abc:someProperty>

>     <swes:SWESEvent>

>       <swes:identifier

> codeSpace="http://www.example.org">a87s9c76s</swes:identifier>

>       <swes:code>CAPABILITIES_CHANGED</swes:code>

>       <swes:service>

>         <wsa:Address>http://my.swe-service.com/path</wsa:Address<http://my.swe-service.com/path%3c/wsa:Address>>

>       </swes:service>

>     </swes:SWESEvent>

>   </abc:someProperty>

> </abc:Wrapper>

>

> Again, I evaluated the expressions with different choice of context node:

> - with context node root node: 1+2+3 are false

> - with context node abc:someProperty: 1 is true ... 2+3 are false

> - with context node swes:SWESEvent: 1+2 are false ... 3 is true

>

> What do you think?

>

> Best regards,

> Johannes Echterhoff