Title: Message
Martin:
-----Original Message-----
From: Martin Chapman
[mailto:]
Sent: Friday, April 16, 2004
10:08 AM
To: 'Jacques Durand'; 'Sunil Kunisetty';
Subject: RE: [wsrm] [Fwd: Comments on
WS-Reliabilty CD 0.992]
-----Original Message-----
From: Jacques Durand
[mailto:]
Sent: 15 April 2004
01:00
To: 'Sunil Kunisetty';
Cc:
Subject: 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:]
Sent: Wednesday, April 14, 2004 2:33 PM
To:
Cc:
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."
<MC> fine
</MC>
> 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>
>
_________________________________________________________________
