RE: [wsdm] choices for expressing messaage patterns for topics

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

I have doubts about viability of nested predicates. I need to confirm that yet. I know that when context is setup properly the expression #2 works just fine, on the other hand. So, I suggest that we use #2 AND indicate that namespace context when evaluation the expression should be so and so. That is the expression MUST literally be exactly as it stands in the spec with exactly the context we specify. So it is not important how yoou get it in a SOAP message or if the context is specified there or not. Our spec says what it needs to be.

-----Original Message-----
From: Murray, Bryan P. [mailto:bryan.murray@hp.com]
Sent: Fri 11/19/2004 8:27 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Cc:
Subject: RE: [wsdm] choices for expressing messaage patterns for topics

Igor,

 

I missed this message earlier. I suggest a variant of your variants that is a little bit different:

 

  //ManagementEvent[namespace-uri(.)="..." and count(Event[namespace-uri(.)="...")]

 

I don't think we should lock in the namespace prefixes in the message patterns. Just performing a SOAP query for the TopicSpace could result in the prefixes getting munged - not good.

 

I will use the above pattern for the MUWS TopicSpace

 

Bryan

---

From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Thursday, November 18, 2004 6:47 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] choices for expressing messaage patterns for topics

For those not interested in details of other choices I'm suggesting #2. Unless I hear the opinions I will use that in MOWS when declaring topics for events.

 

#1 uses prefixes, defines the situation and custom event element

 

//muws-xs:ManagementEvent[muws-xs:Situation/muws-xs:SituationCategory//muws-xs:ReportSituation and my:Event]

 

#1.1 if category is not fixed for the event (i.e. for those events when situation is not fixed)

 

//muws-xs:ManagementEvent[my:Event]

 

#2 variant #1 with count (where appropriate). If multiple my:Event elements are allowed it will look like #1 anyways.

 

//muws-xs:ManagementEvent[muws-xs:Situation/muws-xs:SituationCategory//muws-xs:ReportSituation and count(my:Event)=1]

 

#2.1

//muws-xs:ManagementEvent[count(my:Event)=1]

 

Note that the result of #2 is *precisely* the nodeset of the notification messge contents which is great for understanding

 

#3 variant #2 without prefixes (very long).

 

//ManagementEvent[namespace-uri(.)="..." and Situation[namespace-uri(.)="..."]/[namespace-uri(.)="..."]SituationCategory//ReportSituation[namespace-uri(.)="..."] and count(Event[namespace-uri(.)="..."])=1]

 

#3.1

 

//ManagementEvent[count(Event[namespace-uri(.)="..."])=1]

 

I believe that we may be better off with #2 for use in the spec.

My fear of #3 is that even thogh nested predicates are allowed by XPath 1.0 I'm not sure if that can be processed equally well by all existing implementations, while #2 is very likely to work when the namespace context is setup accordingly.