RE: [wsn] QueryExpression type

["Patil, Sanjay" <sanjay.patil@sap.com>]

In the item 3 below, you say - "We don't require the topic identifier to be carried in the NotificationMessage,...". However, the NotificationMessageHolderType in the latest WSDL has Topic as a mandatory element. I wonder if you were referring to the case of raw notification messages (which obviously does not require a Topic identifier).

Also, should some text describing the purpose for each level of filtering (along with a quick example) be included in the spec?

Thanks,
Sanjay



> -----Original Message-----
> From: Peter Niblett [mailto:peter_niblett@uk.ibm.com] 
> Sent: Thursday, Jul 01, 2004 8:38 AM
> To: David Hull
> Cc: Steve Graham; wsn@lists.oasis-open.org
> Subject: Re: [wsn] QueryExpression type
> 
> 
> 
> 
> 
> 
> David
> 
> I concur with Steve's explanation (this is the "Three levels 
> of filtering"
> thread)... so with an author's hat on...
> 
> 1. Selectors filter based on the values of fields that form 
> part of the
> message content
> 
> 2. Preconditions filter on things that are known to the
> NotificationProducer, but don't necessarily appear in the messages. As
> Steve says, a particular NotificationProducer might have an internal
> property called DEBUG_ON. A precondition lets you filter on DEBUG_ON =
> "true" without requiring that the NotificationMessages all 
> contain DEBUG_ON
> = "true"
> 
> 3. Topics are used to identify the class/classes of situation that the
> Subscriber is interested in. We don't require the topic 
> identifier to be
> carried in the NotificationMessage, so Topic filtering can't always be
> achieved using selectors (and as you say, there are also performance
> considerations that motivate having a separate topic expression).
> 
> You also asked why Precondition and Selector have type
> wsrp:QueryExpressionType while TopicExpression has type
> wsnt:TopicExpressionType, since if you look into the content models of
> these types, they look identical. If we were - hypothetically 
> - to change
> the declaration of TopicExpression so that its type became
> wsrp:QueryExpressionType (or indeed some other type like
> wsxx:AnyWithDialect that happened to have the same content 
> model) then our
> new schema would still validate precisely the same set of XML 
> instances as
> the current one.
> 
> I think the reason for having distinct type defnitions is to 
> imply a sense
> of typing, even though it can't be enforced by schema validation. The
> dialects that you use for Precondition/Selector might well be 
> different
> from the set of dialects used for TopicExpression (and so would have
> different URIs) hence the reason for using different types. 
> The reason for
> using wsrp:QueryExpressionType for Precondition and Selector 
> is to suggest
> to implementors that they consider supporting the same dialects for
> Precondition/Selector as they do for querying Resource Properties in
> WS-ResourceProperties.
> 
> Peter Niblett
> IBM Senior Technical Staff Member
> 
> 
> 
> 
>                                                               
>              
>              Steve Graham                                     
>              
>              <sggraham@us.ibm.                                
>              
>              com>                                             
>           To 
>                                        David Hull 
> <dmh@tibco.com>          
>              30/06/2004 21:41                                 
>           cc 
>                                        
> wsn@lists.oasis-open.org            
>                                                               
>      Subject 
>                                        Re: [wsn] 
> QueryExpression type      
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
> 
> 
> 
> 
> 
> David:
> Thanks for this analysis.  With regards to Precondition, 
> Selector (filter)
> and Topic, yes I agree that these are similar concepts of 
> "reducing the
> number of possible notifications" that "match" the subscription.
> 
> Part of the reasoning (if I can recall it) for the 3 
> different forms is
> roughly as follows:
> 
> Topic, and TopicSpaces, and the way that the producer uses 
> them is (for the
> most part) under its control.  The subscriber cannot directly 
> influence the
> topic space.  If the producer's choice of Topics (ie how it 
> "partitions"
> the set of all notifications the producer wishes to accept 
> subscirptions
> for) is outside of the control of the subscriber.  If the 
> producer chooses
> a very coarse grained topic model, then the subscriber would 
> either have to
> take all messages on a given topic (even if only a subset 
> were desired), or
> ... the consumer could avail itself of the selector mechanism.
> 
> So... the selector mechanism was put in place to provide the 
> subscriber a
> means of specifying producer side filtering.  This gives the 
> subscriber
> some amount of control, that is not available if we only had the Topic
> mechanism of doing "filtering".  Now a fair question might 
> be, great, you
> have selector, why do you need topics?  Well, one answer (I 
> suspect there
> are many more) suggests that with Topics, there is a large amount of
> producer-side security and performance QoS opportunities than 
> are possible
> with "only" selector.
> 
> Now... the question that often comes up is why does one need 
> both selector
> and precondition.  This is a much harder question.  This 
> boiled down to
> some use cases related to "subsetting" the notification 
> message stream.
> There are certain circumstances that are not contained in the message
> itself (so selector cannot be used) that affect whether notificaitons
> should be delivered on a subscription.  So, for example, 
> imagine there was
> a DEBUG_ON resource property. I could specify a precondition on the
> subscription that DEBUG_ON = "true".  This allows non-message based
> conditions to also be applied to the topic and selector based means of
> doing notification message subsetting.
> 
> sgg
> 
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On Demand Architecture
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
> 
> 
>                                                               
>             
>     David Hull <dmh@tibco.com>                                
>             
>                                          To:                  
>             
>                                  wsn@lists.oasis-open.org     
>             
>     06/30/2004 03:37 PM                  cc:                  
>             
>                                          Subject:        
> [wsn]            
>                                  QueryExpression type         
>             
>                                                               
>             
> 
> 
> 
> 
> 
> After re-reading in more detail, I believe one of my previous comments
> on precondition and selector was slightly off.
> 
> These elements are defined as having type QueryExpression, 
> which is just
> a dialect attribute and mixed content.  I had mistakenly assumed they
> contained an element of type QueryExpression.  As the sample message
> shows, the precondition element in the subscribe message already looks
> like I suggested it should.
> 
> The main difference between Precondition and Selector on the one hand
> and TopicExpression on the other is that TopicExpression has type
> wsnt:TopicExpressionType while the others have type
> wsrp:QueryExpressionType.  The two types have essentially identical
> definitions.
> 
> In either case, we want to be able to allow any kind of content but
> easily and explicitly know what sort of content it is.   It seems odd
> that we have two different definitions of "arbitrary content 
> tagged with
> a dialect ID".  If this concept is useful, it seems more generally
> useful than either topic expression or query expression.  An 
> alternative
> would be for all three elements to have the same type, and 
> for that type
> to have a more generic name than "QueryExpression".
> 
>