RE: context node for XPath filter dialect ambiguous?

I can't see the highlighting but I'm assuming the new sentence is:
        XPath expressions provided for the event filtering should take 
into account the notification format (wrapped or unwrapped).
The XPath expression is evaluated over the event data itself regardless of 
what Format is used (wrapper or unwrapped) - meaning the raw (unwrapped) 
version:
        (Section 4.1): Context Node: the root of the event XML. 

This was done on purpose so that regardless of which Format URI is used, 
the filtering expression would remain the same - this is important because 
Filtering comes before the Formatting:
(Section 2.3): Filtering occurs prior to any formatting of notification 
messages. This ensures that regardless of what type of formatting might 
occur, the same Filter dialect/expression can be used to subset the event 
stream. 

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.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
12/07/2009 05:35 PM

To
"johannes.echterhoff@igsi.eu" <johannes.echterhoff@igsi.eu>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
cc

Subject
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>
>   </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>
>       </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