OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Sunil, Martin:
Generally agree, though some comments... see inline <JD>

Jacques

-----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]



 Few comments on the CD 0.992 draft from Martin Chapman.

 Tom,

 Can we discuss this on the next week's call?

 -Sunil


> 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.

> 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.

>
> 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."
> _________________________________________________________________



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]