Re: context node for XPath filter dialect ambiguous?

I think Johannes is really looking for some example event data and some 
likely XPath expressions that do and do not result in the transmission 
of a notification of that event.

- gp

On 12/7/2009 2:35 PM, Ram Jeyaraman wrote:
>
> 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
>
>  
>
>  
>
>  
>
>  
>