AI0006 - variants of WS-Topics to address issue WSN 4.29

[Peter Niblett <peter_niblett@uk.ibm.com>]

I have discussed this question with William and here is an evaluation of
the variants proposed in the attached email..

We have identified 4 desirable characteristics

a) Preserving the nesting of dialects (Simple being a subset of Concrete;
Concrete a subset of Full, Full a subset of XPath)
b) Maintaining the purity of the XPath expressions (i.e. each expression
should be interpretable as an XPath)
c) Allowing multiple paths to a Topic set (in particular allowing access to
an Extension Topic without requiring you to start from the parent Topic
Namespace)
d) Not requiring a topic in more than one place in a TopicSet document
(simplifies the TopicSet and avoids potential inconsistencies)

All four options listed presented achieve a).

Options 1,2,3 achieve b). Option 4 does not, since the way the expression
is interpreted depends on whether its first component is an extension topic
or not.

Options 1 and 4 achieve c). Option 2 permits it (the implementor can
choose). Option 3 almost achieves 3, but only if you are using a dialect
that permits //

Options 3 and 4 achieve d). Option 2 permits it (the implementor can
choose). Option 1 does not.

Transposing this data:

Option 1 achieves a), b), c)
Option 2 achieves a), b), permits c) and d)
Option 3 achieves a), b, d) and partly achieves c)
Option 4 achieves a), c), d)

Our recommendation is to go with Option 3.

Our rationale is as follows:

Option 2 is too liberal - a would-be subscriber would have to know too much
about about the implementation choices made by the Producer. Also fully
achieving c) and d) are mutually exclusive - to "permit" both on Option 2
is essentially Option 3.

Option 1 and Option 4 suffer from defects d) and b) which in our opinion
are worse than not fully achieving c). The only drawback of Option 3 is
that you can't get to a ExtensionTopic using just the Simple dialect, but
that's what Concrete is for.


Peter Niblett




                                                                           
             Peter                                                         
             Niblett/UK/IBM@IB                                             
             MGB                                                        To 
                                       wsn@lists.oasis-open.org            
             24/04/2006 12:33                                           cc 
                                                                           
                                                                   Subject 
                                       [wsn] AI0003 - variants of          
                                       WS-Topics to address issue WSN 4.29 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           



I attach three versions of WS-Topics showing the changes to be made to
WS-Topics depending on which of the approaches we take to issue 4.29.

Consider the example where tns2:t3 is an extension of tns1:t1



1. Baseline (no change) is given in
http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/17606/wsn-ws_topics-1.3-spec-wd-02a.doc


In this version the NP is required to insert an ExtensionTopic in every
possible place in the TopicSet document, so all paths are permitted. In
this case tns1:t1/tns2:t3 and tns2:t3.
This means that simple Topic Expression dialect tns2:t3  could be used.

2. The 2a-bis version
(See attached file: wsn-ws_topics-1.3-spec-wd-02a - bis.doc)
In this version the NP is given free hand to choose where and how many
times to insert the ExtensionTopic in the TopicSet, and so can choose which
paths to allow. If it chooses not to allow tns2:t3 then simple Topic
Expressions cannot be used.


3. The 2a-ter version
(See attached file: wsn-ws_topics-1.3-spec-wd-02a - ter.doc)

In this version the NP is required to insert the ExtensionTopic into the
TopicSet just once  - an in the position that permits only the "fully
expanded" path - i.e. tns1:t1/tns2:t3.  Simple TopicExpressions can't be
used, and Concrete Expressions are required to provide the full path. Full
and XPath expressions can use wildcard // to avoid having to spell it out
in full.

4. The 2a-quater version

(See attached file: wsn-ws_topics-1.3-spec-wd-02a - quater.doc)


As in the 2a-ter version the NP is required to insert the ExtensionTopic so
as to permit only the "fully expanded" path - i.e. tns1:t1/tns2:t3.
However the definitions of the dialects are adjusted to permit either
tns1:t1/tns2:t3 or tns2:t3. In the case of Simple and Concrete expressions
(which don't actually refer to the TopicSet document) I added words to
state that path may start from the ExtensionTopic itself. In the case of
Full and XPath it requires the expression to be analysed and if it is found
to start with an Extension Topic, then a // is implicitly prepended.

 All versions preserve the "nesting" of the dialects.. i.e. Simple is a
subset of Concrete, is a subset of Full, is a subset of XPATH.

Peter Niblett(See attached file: wsn-ws_topics-1.3-spec-wd-02a - bis.doc)
(See attached file: wsn-ws_topics-1.3-spec-wd-02a - ter.doc)(See attached
file: wsn-ws_topics-1.3-spec-wd-02a - quater.doc)

wsn-ws_topics-1.3-spec-wd-02a - bis.doc

wsn-ws_topics-1.3-spec-wd-02a - ter.doc

wsn-ws_topics-1.3-spec-wd-02a - quater.doc