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

[Heather Kreger <kreger@us.ibm.com>]

I think option 2 looks ok for me. 

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572

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

11/18/2004 09:47 PM

To	<wsdm@lists.oasis-open.org>
cc
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.