RE: [wsn] 4.4 and 4.28 issues verification

["Vambenepe, William N" <vbp@hp.com>]

Hi Peter,

Thanks for the comprehensive reply.

Your reworded 3rd bullet of 6.1 looks good.

You are right about 4.28 subissue 4.

I agree that 4.28 subissue 7 is taken care of by the text you provide.
This text is actually the reason why I said I thought there was enough
of an explanation. I just didn't realize that this was new text, which
is why I said I didn't find additional explanation but I didn't think
additional explanation was needed. Anyway, it's all good now.

The only issue left is 4.4 comment 2. My take is "yes" on (a) and I
think the real question is whether to answer yes or no on (b). One of my
concerns w/ yes is the fact that metadata might then be inconsistent
between two representations of the same topic. In any case, I agree w/
you that this is something that can be discussed as part of public
review.

Regards,

William

-----Original Message-----
From: Peter Niblett [mailto:peter_niblett@uk.ibm.com] 
Sent: Tuesday, December 06, 2005 8:37 AM
To: Vambenepe, William N
Cc: wsn@lists.oasis-open.org
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.