[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]