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

["Murray, Bryan P." <bryan.murray@hp.com>]

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.