choices for expressing messaage patterns for topics

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

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.