W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > December 2009

AW: context node for XPath filter dialect ambiguous?

From: Johannes Echterhoff <johannes.echterhoff@igsi.eu>
Date: Tue, 1 Dec 2009 19:47:41 +0100
To: <public-ws-resource-access@w3.org>
Message-ID: <00c701ca72b6$c37a0a90$4a6e1fb0$@echterhoff@igsi.eu>
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
Received on Tuesday, 1 December 2009 18:48:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:16 GMT