AW: context node for XPath filter dialect ambiguous? from Johannes Echterhoff on 2009-12-16 (public-ws-resource-access@w3.org from December 2009)

From: Johannes Echterhoff <johannes.echterhoff@igsi.eu>
Date: Wed, 16 Dec 2009 09:05:44 +0100
To: "'Gilbert Pilz'" <gilbert.pilz@oracle.com>, "'Ram Jeyaraman'" <Ram.Jeyaraman@microsoft.com>
Cc: <public-ws-resource-access@w3.org>
Message-ID: <005501ca7e26$9200e670$b602b350$@echterhoff@igsi.eu>
Hi.

 

Yes, in the end that would help understanding Xpath based filtering a lot.
There is one example in the specification – maybe an Annex can provide a
more elaborate example with multiple expressions – up to you.

 

My original issue was with filtering wrapped / unwrapped notification
content, but that issue was solved (or rather: the document already
specified that the xpath expression must be applied before adding any
wrapper to an event, which is exactly what should be done).

 

Thanks.

Johannes

 

 

Von: public-ws-resource-access-request@w3.org
[mailto:public-ws-resource-access-request@w3.org] Im Auftrag von Gilbert
Pilz
Gesendet: Mittwoch, 16. Dezember 2009 02:16
An: Ram Jeyaraman
Cc: johannes.echterhoff@igsi.eu; public-ws-resource-access@w3.org
Betreff: 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>
http://www.opengis.net/swes/1.0"

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

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

>   <swes:identifier

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

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

>   <swes:service>

>     <wsa:Address> <http://my.swe-service.com/path%3c/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>
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>
http://www.opengis.net/swes/1.0"

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

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

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

>   <abc:someProperty>

>     <swes:SWESEvent>

>       <swes:identifier

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

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

>       <swes:service>

>         <wsa:Address> <http://my.swe-service.com/path%3c/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 Wednesday, 16 December 2009 08:06:23 UTC