RE: [wsrm] [Fwd: Comments on WS-Reliabilty CD 0.992]

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: 15 April 2004 01:00
To: 'Sunil Kunisetty'; wsrm@lists.oasis-open.org
Cc: martin.chapman@oracle.com
Subject: RE: [wsrm] [Fwd: Comments on WS-Reliabilty CD 0.992]

-----Original Message-----
From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
Sent: Wednesday, April 14, 2004 2:33 PM
To: wsrm@lists.oasis-open.org
Cc: martin.chapman@oracle.com
Subject: [wsrm] [Fwd: Comments on WS-Reliabilty CD 0.992]

> Only one area needs major tree surgery: section 1.7 should be merged with appendix II and placed in its own top level section. This is the part of the doc that threw me most.

>
> The rest are (minor) suggestions to improve readability and comprehension.
>
> Line 101 - 114: editorial: delete all these lines as its castes too much doubt on the spec.
>

<JD> How about rewording instead like:
"Reliability is often associated with QoS quantitative measures, in areas other than Web services (e.g. networking). Thresholds such as rate of failures, minimal size of persistent store, average latency, and more generally quantitative measures that may appear in service level agreements, are out of scope for this version."

> Line 150 - 271: editorial: I find it strange that we launch into example messages without any form of introduction.
> Maybe better to insert a paragraph to explain a scenario from whish these messages are derived. And also there really should be an fuller explainaion of a the reliability elements.

>
<JD> we have some explanation at the end of each example. We could move this up
before introducing each example, instead of after.

<mc> the text is very terse. If you look at other specs they really walk though all the relevant elements and explain what is going on </mc>
[Jacques Durand] Let us ask our editor, I think there was some intent to give an up-front flavor of the headers, that the reader could go back to as s/he progresses through the spec. (I expressed in the past my preference to see these examples at the end of doc, but can understand this rationale. Now, question remains how much walk through can we do up-front without much knowledge of the spec...)

> line 358: editorial: the whole of section looks out of place. It uses a lot of terminology that has not yet been introduced. It is also strongly related to appendix II. I suggest moving the whole of 1.7 into a new top level section after section 5 (i.e. make it a new section 6) and then merge in appendix II.

<JD> the problem with moving the agreement definitions after Sec 5, is that we refer to them
throughout the spec, starting with Sec 3, when introducing RM features.
Why not have a new section between Sec 2 and Sec 3 (i.e. previous Sec 3 becomes 4, etc.)
However, when doing so I would not import the entire Appendix A/II up front, as I think
it is unsettling for the reader who expects to get right at the core features
with as little distraction as needed... so I would provide some introduction material
on the rationale for adding capability info to WSDL, and the approach recommended, and
then refer to Appendix A for the hard stuff. Also if we combine the agreement and the
f&p stuff, clearly state that even if they complement each other, they don't need each other.

<mc> maybe i missed something but thr agreement stuff is sort of meaningless without a way to express it. Granted there may be many ways to do this, with f&p being one of them. If this is what you mean then fine.
[Jacques Durand] We thought this over, and concluded that agreements can remain abstract and still be meaningful here: in fact, it is the only proper way to connect to "outside" agreements while keeping their representation open. We describe our RM features like: "if <agreement-item-XYZ> is enabled (or has value ABC), then the message protocol must look like this, the behavior must be like that." Just describing the protocol on teh wire was ignoring the agreement aspect. Also, some features like resending messages (and related parameters, like # of retries, etc) would not even appear in the message protocol. We needed to be able to talk about the behavior they cause even if they don't have a concrete representation.

Generally though, the agreement stuff is very detailed, and the detail is launched into without any overview of rationale.This is my main conecern so even putting that in its own section may not help. </mc>
[Jacques Durand] Agree. Will propose something.

>
> line 444: editorial: I suggest adding a paragraph or two here that does provide a very high overview of the model. The subsequenst sub section dive into details without giving the reader an overview on which to elaborate. I suggest using the text in the pre-Tc version that was published:

>
> "In the Reliable Messaging Model described in this document, the sender node sends a
> message to the receiver node directly (i.e., intermediaries are assumed to be
> transparent in this specification). The receiver node sends back an Acknowledgment
> message to the sender node. Figure 1 shows this model.
> Figure 1 Messaging Model"
>
> This should provide enough context
>
<JD> Isn't that very similar to the first bullet item of 2.1 ?
No problem with this rewording though.
But the transition to 2.2 (and Figure 1) probably calls for another sentence like:
" the basic exchange patterns described in 2.2 derive from the above messaging assumptions.
Reliability features defined in this specification will in turn rely on these patterns."

<mc> fine </mc>
> _________________________________________________________________

wsrm message