[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsn] 4.4 and 4.28 issues verification
Summarising just the 4.4 part of the discussion, to save people having to read the rest.... The WS-Topics spec allows a root Topic to be given an attribute that points it at an element in another TopicNamespace, this causes the tree descended from that Topic to be "rooted" in the second Namespace. So if I have two Namespaces tns1 and tns2 with tns1 containing A/B, tns2 containing C/D, then I can place tns2:C as a child of tns1:A/B It is our intention that users should be able to subscribe to the "D topic" using either of these two expressions: tns1:A/B/tns2:C/D or tns2:C/D The question is about the means of achieving this when constructing the TopicSet document. Recall that at the moment this is an XML document against which we execute the XPATH expression in order to determine which Topics match the Topic filter. Do we a) State that the document is constructed to contain two nodes for D, corresponding to the 2 possible locations. With this approach the TopicSet is more complicated and allows for the possibility of mismatching metadata the William mentions, but the description of how you evaluate the XPATH expression is simpler. or b) State that the document only contains one node for D (e.g tns1:A/B/tns2:C/D) and that the XPATH expression is pre-processed to resolve this.. In other words if the expression starts with something that isn't a root in the TopicSet, but is an extension of something else ( a "parent") then the XPATH expression is pre-pended with the path to that parent. Of course that itself might be in an extension Namespace so this process has to continue recursively until the XPATH expression starts with something that is a root topic in the TopicSet. This approach keeps the TopicSet instances simpler but makes the description of the XPATH evaluation more complex. The current draft went for option a), simply to keep the wording in the spec simpler. Peter "Vambenepe, William N" <vbp@hp.com> To Peter Niblett/UK/IBM@IBMGB 08/12/2005 18:24 cc <wsn@lists.oasis-open.org> Subject RE: [wsn] 4.4 and 4.28 issues verification 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]