Re: [wsn] QueryExpression type

[Steve Graham <sggraham@us.ibm.com>]

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> 06/30/2004 03:37 PM

To:        wsn@lists.oasis-open.org         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".