Issue 4.29 - options

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

This issue concerns the way we represent an extension topic in a Topic Set

Suppose I have a TopicNamespace tns1:, with a root topic A and a second
TopicNamespace tns2: with a topic B which is an extension of A.

We agreed a while back that we wished to allow two possible paths to this
second topic..

tns1:A/tns2:B

and

tns2:B.

There are two ways that this can be expressed in the spec

Option 1. Require multiple entries in the TopicSet document. This is the
approach currently taken in PR draft 1 lines 479...


If a Topic is defined as an extension of another Topic, or a child of such
an Extension Topic, then it is represented by multiple elements in the
TopicSet document, corresponding to the multiple paths that can be used to
access it. There are always at least two such paths. One path starts with
the Extension Topic itself, so the Extension Topic appears as a top-level
child of TopicSet, the other starts with the root Topic that contains its
parent Topic. There may be further paths if the parent itself is an
Extension Topic or a child of an Extension Topic.


Note that this approach does let the Producer choose whether it wishes to
permit multiple paths or not, but it results in a more complex TopicSet
document and could lead to confusion if the producer associated different
metadata with each instance in the TopicSet.

Option 2. Define normatively the an algorithm that preprocesses the
TopicExpression to expand all extension topics.  To do this we would

a) Delete the paragraph starting in line 479 that I just quoted and instead
state that each Extension Topic is added just once to the TopicSet (note
that as today this may result in its parents having to be added as well)

b) Replace the text describing full TopicExpressions in section 8.3 with
something like the following

###Existing text


Full TopicExpressions are XPath 1.0 [XPATH] relative location path
expressions with some additional syntactic constraints listed in this
section. The XPath expression is evaluated over a NotificationProducer’s
TopicSet document as defined in section 7. The TopicExpression identifies
the set of Topics that correspond to the elements in the node-set that
results from evaluating the location path contained in the TopicExpression,
using standard XPath 1.0.  The initial context node for this evaluation is
the wstop:TopicSet root element. Note that some of the elements returned by
the evaluation may not correspond to Topics (these are elements which do
not have @topic=”true”).

###Existing text ends

###Replacement text

Full TopicExpressions are XPath 1.0 [XPATH] relative location path
expressions with some additional syntactic constraints listed in this
section.

The expression is examined and its RootTopic is examined to see if it is an
ExtensionTopic. If it is an ExtensionTopic then a new expression is
produced by subsitituting the Parent topic in place of the the Root Topic.
This process is then repeated recursively against the new expression until
an expression is produced that does not have an Extension Topic as its
root. The expression produced by this process is then evaluated over a
NotificationProducer’s TopicSet document as defined in section 7. The
TopicExpression identifies the set of Topics that correspond to the
elements in the node-set that results from evaluating the location path
contained in the TopicExpression, using standard XPath 1.0.  The initial
context node for this evaluation is the wstop:TopicSet root element. Note
that some of the elements returned by the evaluation may not correspond to
Topics (these are elements which do not have @topic=”true”).

###Replacement text ends

c) Do something similar for section 8.4 (XPath topic expressions)

d) Replace the definitions of Simple and Concrete Topic Expressions (8.1
and 8.2) to say that they are to be interpreted as Full Topic expressions,
and thus pick up the text in b)

e) Add some guidance to TopicSet designers about the need to avoid circular
references


Peter Niblett