[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsn] QueryExpression type
Sanjay
You are right that the NotificationMessageHolderType carries a mandatory
Topic element, but there's no requirement to put a topic identifier in the
body of the NotificationMessage itself, and in the raw notification pattern
this is all there is in the message. I think the intention of the
specification was that the selector in a subscribe request is evaluated
against this body, rather than the entire Notify message.. and so the topic
- even though it is carried in the Notify message - is not available to be
used as part of a selector expression.
The reasoning behind this is
a) The selector expression is the same, regardless of whether the subscribe
request has useNotify=true or useNotify=false.
b) If the subscription is using the useNotify message, we allow the
NotificationProducer to batch together several NotificationMessages into a
single Notify message. I don't think it is reasonable to expect subscribers
to have to cope with this when constructing selectors; it's more
straightforward to say that the selector is expressed in terms of a single
NotificationMessage, rather than the actual Notify message that is sent.
I agree that this might not be immediately apparent from the words in the
spec - in particular as we say in 4.2 that "The evaluation context is
NotificationMessage(s) that are Published..." yet the <NotificationMessage>
element in the Notify message is actually the wrapper that contains the
Topic as well as the message body.
The spec has a few words on the purpose of the different kinds of
filtering, however it doesn't really give any examples. I agree that we
need some more non-normative material to explain this, but it looks to me
as if that is something we should put in the primer.
Regards
Peter Niblett
IBM Senior Technical Staff Member
"Patil, Sanjay"
<sanjay.patil@sap
.com> To
Peter Niblett/UK/IBM@IBMGB, David
09/07/2004 00:27 Hull <dmh@tibco.com>
cc
Steve Graham <sggraham@us.ibm.com>,
wsn@lists.oasis-open.org
Subject
RE: [wsn] QueryExpression type
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".
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]