[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsn] 4.4 and 4.28 issues verification
William
Thank you very much for doing a speedy review. I'm posting a draft 01g with
your comments addressed as follows...
WSN 4.4 Comment 1:
--------------------------------
I have reworded the definition of @parent to include a pointer to 6.1 as
you suggested:
/wstop:Topic/@parent
An optional attribute whose value is a ConcreteTopicExpression. It
designates a parent Topic and indicates that this root Topic, and any
child Topics descended from it, are extensions of that parent. See
section 6.1 for a description of extension Topics. This attribute MUST
NOT be used on Topics other than root Topics.
I have also reworded bullet 3 of 6.1, as the previous text was a bit loose
with the situation where the parent was a child of an Extension Topic. Can
you check that it makes sense?
3. The Topic referenced by the @parent attribute MAY be an Extension Topic
or the child of an Extension Topic, however it MUST be possible to follow a
chain of Extension/parent/root Topics back to a root Topic that is not an
Extension Topic. Moreover a given Topic Namespace MUST NOT appear more than
once in this chain.This means that circular references, e.g. A extends B /
B extends A are NOT permitted.
WSN 4.4 Comment 2:
--------------------------------
I think there are two questions here:
a. Should a NotificationProducer be required to support all possible paths
to an Extension Topic (or a child of an Extension Topic)?
b. Should a NotificationProducer be required to put all supported paths in
the TopicSet?
I'm not sure whether you are asking question a. or question b. (In the
draft 01f I assumed an answer of Yes to both of them).
If the answer to a, is No, then presumably the answer to b, has to be Yes,
so that a Subscriber knows what paths are supported. However I think the TC
decided the answer to a. is Yes - here are some excerpts from the minutes
of the morning of the Feb1 F2F...
-------------------------------------------------------
1. tns2:A/B/C/D (vendor has copied the orginal topic space)
2. tns1:A/B/C/D (printers.org has grown the tree for vendor.org)
3. tns1:A/B/tns2:C/D (fully namespaced qualified reference, like XPath)
4. tns2:C/D (utilize metadata to do the connection/inheritance)
....
Group likes 3 + 4. Starting from tns2:C will always act as if
prepending tns1:/A/B. Change the syntax to permit namespace prefixes.
Define rule which states that namespaces propagate forward (rightwards)
where no namespace is defined.
----------------------------------------------------------
I guess it is valid to answer Yes to a. and No to b. The NP would only be
required to insert one of them into the TopicSet document (presumably the
fully expanded one) and readers of the TopicSet document would be then
infer the existence of the other paths. This has the advantage that the
TopicSet is simpler. However it would mean that we would have to change the
definition of the Full and XPath Topic Expressions. At the moment these
are defined to be XPath relative locationPaths evaluated against the
TopicSet document. We would have to add words to say that these Expressions
are first run through a preprocessor which recursively expands the first
node-test in the path until it stops being an Extension Topic, before being
evaluated against the TopicSet document. This seems to lose sight of the
reason we introduced the TopicSet in the first place (namely to materialise
the document that the Expressions ran against).
I think this needs a longer discussion, so I suggest leaving the text as it
is for now and we can consider it further during the Public Review Period.
WSN 4.28 Subissue 1. Definition of Situation
-----------------------------------------------------------------
I have replaced WSNotification with WS-Notification .
WSN 4.28 Subissue 4. The value of the MessagePattern element in
pseudo-schema
-------------------------------------------------------------------------------------------------------------------------
The change of wsrp:QueryExpressionType to wstop:QueryExpressionType (rather
than wsnt:QueryExpressionType) is deliberate and is to avoid the circular
dependency of schemas (BaseN importing Topics and vice versa) - that's the
difference between draft 01e and 01f which I mentioned on yesterday's call.
The approach agreed for WSN 4.21 (removing the dependency on WSRP) was to
"adopt the same approach as 2.41". Since 2.41 copied the
wsrp:QueryExpressionType into the wsnt schema, this statement could be
interpreted either as "reuse wsnt:QueryExpressionType" or "copy
QueryExpressionType into the wstop: schema". At the time that Kirk raised
his issue we had implemented 4.21 by reusing the wsnt:QueryExpressionType,
we now do it by introducing a wstop:QueryExpressionType (see the schema at
line 944) which is cleaner as it avoids this extra dependency. As it
happens this change has no effect on what you put in the XML document, it's
merely a question of where the type gets defined. So I suggest we leave the
pseudo-schema as it is in draft 01f - it does now match the schema which I
think was Kirk's main point.
WSN 4.28 Subissue 7. Rationale for having both TopicSet and
TopicExpressionLists as RPs
---------------------------------------------------------------------------------------------------------------------------------------
I put some text that tried to addess this at lines 806+ in section 11. I
agree it doesn't really say WHY we decided to have two approaches, but it
does indicate some advantages of each:
"The NotificationProducer MAY support Resource Properties
[WS-ResourceProperties] that indicate the set of Topics that it expects to
handle. WS-BaseNotification defines two resource properties that can be
used for this purpose.
1. The NotificationProducer MAY support the wstop:TopicSet resource
property, which returns the entire Topic Set as a single XML element as
defined in section 7,
2. The NotificationProducer MAY support the wstop:TopicExpression
resource property. This resource property returns a list of
TopicExpressions covering the set of supported Topics.
The first approach has the advantage that the ResourceProperty returns the
document used to evaluate Topic subscription filters that use the Full or
XPATH dialects. It allows the NotificationProducer to insert
producer-specific metadata that can be used in filters constructed using
the XPATH dialect.
The second approach is simpler in the case where the NotificationProducer
only supports Simple or Concrete Topic Expression dialects (it is merely
the list of supported expressions). It could be more concise in cases where
NotificationProducers support Full or XPath Topic Expression dialects since
such a NotificationProducer could use a wildcarded TopicExpression to cover
more than one Topic.
A NotificationProducer is free to support either, both, or neither of these
ResourceProperties."
Regards
Peter Niblett
"Vambenepe,
William N"
<vbp@hp.com> To
<wsn@lists.oasis-open.org>
05/12/2005 20:43 cc
Subject
[wsn] 4.4 and 4.28 issues
verification
Hi all,
I went through the issue verifications assigned to me. See the results
below. Only a few comments.
Thanks a lot Peter for the careful editorial work, especially taking
care of 4.4 which was pretty tricky to do properly.
William
Issue 4.4:
VERIFIED. The agreed-on change is well reflected in the document. I just
have 2 comments:
1) The description for the /wstop:Topic/@parent attribute should point
to section 6.1 for more info on what "extension" means here (at first
read I didn't realized there is an additional description and I was
puzzled).
2) I am a bit puzzled by this new paragraph in section 7:
"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."
This seems to imply that in order to include an extension topic in a
topic set you MUST include it using all the paths that work for it. It
seems to me that it should be enough to include it once.
Issue 4.28: see subsections below.
1. Section 2: third bullet under the definition of Topic (as well as
line 719) refers to "Situation". Should make it clear that Situation
(the capitalized, technical term) is defined byt he WS-BaseNotification
specification.
VERIFIED (that sentence has a minor typo, "WSNotification" instead of
"WS-Notification".
2. Line 231: TopicExpression dialects are now defined in section 8 (the
1.3c draft says "section 7").
VERIFIED
3. The wstop:TopicNamespace/@location attribute is shown in the
pseudo-schema at the beginning of section 5, but is not documented in
the the text (see p. 12) and does not appear in the Schema.
VERIFIED
4. Line 353 (pseudo-schema at the start of section 6) shows the value
of the MessagePattern element as wsrp:QueryExpression. It should be
wsnt:QueryExpression (see WSN 4.26) to match the schema.
NOT VERIFIED: the current version does not have a namespace prefix, so
it implies a prefix of wstop, instead of wsnt.
5. Line 368 (definition of Topic) talks about a @namespace attribute
which isn't defined anywhere, It looks as though this should be a
reference to TopicNamespace/@targetNamespace.
VERIFIED
6. The title of section 8 (TopicExpressions) defines some
TopicExpression Dialects, but not the TopicExpression element itself. It
would be better to change the title of the section to "TopicExpression
Dialects".
VERIFIED
7. The spec doesn't contain enough text to allow someone to appreciate
the rationale for having both TopicSet documents and TopicExpression
lists
NOT VERIFIED: I didn't find such additional text, only a pointer to
WS-BaseN for definitions of some terms, which is not what is requested
here. On the other hand, I am not sure that we really need such
additional explanation.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]