RE: [wsrm] About MP8

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [wsrm] About MP8

About MP8:

Frankly , re-reading B6 in Appendix B,
I think we would save ourselves some trouble by just deleting B6 and
replacing it by a simple note in B.5 that "not all agreement items need be mapped by
a property (e.g. GroupExpiryTime, ... etc.)"

For a starter, the "property" definition in B.3.3. (repeated from B.1) includes association with "WSDL element" (although a doubt remains whether this is only the RM Capabilities that are associated with WSDL in this def, but other places suggest the initial assertion is true). The way property is referred to in B.6 (to define the kind

"sender properties") seems to counter this definition, and that is confusing (when deriving from a former definition, you can specialize/extend it, but not invalidate it like this).

Then I am not sure what B.6 brings here, except confusion: where would these
"other (sender) properties" be represented if not in WSDL? what is the use case for this?
we don't even know if these should be represented in a static XML doc, or better off be dynamically calculated, like message ExpiryTime which may partially depend on

network conditions. Intuitively, these sender properties may be relevant to some RMP configuration, but that is implementation specific. For example, ExpiryTime may result from some combination of a "static" value representing some QoS, and of a network-defined parameter. The part that is then defined in a "property" document has then

a different meaning from  the final ExpiryTime result/duration.
Also, the expiry times as currently defined in our spec, are dates and not durations,
and it is a bit confusing to say that their property counterpart must be "durations"
(and this is a MUST because this section is normative though optional...)

SO I am for simply removing B.6., I don't think we would loose anything: on the contrary, it is premature to figure what proerties are needed that are only specific to the Sender side. Sorry for the late wake-up...

Jacques

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Monday, August 02, 2004 4:08 PM
To: wsrm
Subject: [wsrm] What changed in 1.07?

Well, pretty much everything.  The -diff file[1] I provided is not of much
use since it underscores every space or comma deleted and each mundane
change to the document.  The comparison also groups too many small changes
together, ruining the headers (at least) and making it difficult to see
what actually changed.

All outstanding issues were addressed in this revision[2] except the very
few noted below and in the detailed changes documents[3,4] (should be about
the same list).  The "List of action items" document[3] and related
"ReplyTo fixes" document[4] describes most of the technical changes made to
the document.  Please note that we editors may have done some word smithing
and a touch of rearranging as we addressed these issues; such editing will
not be reflected in these two[3,4] documents.

By my count, we have 3 main areas of confusion and issues remaining:
- Response@replyPattern, the subject of my "Technical issues as I go
through action items..." email [not mentioned in the detailed changes
documents[3,4]]

- CF4 or group termination in the case of a catastrophic failure

- MP8 or the meaning of the Other Reliability Properties discussed in B.6

At a lower level of detail,
- the sentence "A property is an assertion or constraint on a specific RM
capability and its value(s) associated with WSDL elements." near the top
(2nd sentence) of B3.3 has given the editors pause.  Mark's original
question was "What's associated with WSDL elements here: a property, a
constraint, an RM capability, or its values?"

- Mark also noted the sentence "For the Callback and Poll RM-Reply
Patterns, a Response element can contain multiple Acknowledgment and/or RM
Fault Indications." near the bottom of Section 6.  This should be redundant
with something in Section 4.4 but the closest "something" is in 4.3.2,
about support for asking questions about multiple groups in a single
PollRequest.  Since Tom seems to be leaning toward removing such
flexibility, I have done nothing to address this issue.

I would recommend particularly thorough review of the changes I made
related to AI 1.4 Action 072004-2, resolution to Chris F comments 1, 2, 10,
19 and 24 -- this exact set of changes has not been discussed within the TC
though it follows much discussion.

Some mundane things besides commas include:
- correcting the 2119 terminology issues I mentioned earlier
   general rule: when requirement is enforced in schema OK to describe in
full text that requirement but without RFC 2119 keywords

- removal of some redundancies between the agreement item descriptions or
abstract model and the element and attribute descriptions in Section 4
   general rule: Check every MUST for redundancy, which may go back to
overall agreement item descriptions.
   general rule: section 4 needs few MUSTs because most will repeat things
in section 3  may find a few rules missing from section 3
   general rule: better to express the requirements at a higher level as
long as that does not lose information and the specific elements are tied
directly to the abstract requirements

- making the links between those elements and attributes and the agreement
items or abstract model more explicit

- adding more document automation -- allowing tables, figures and sections
to reorder and move without further problems.  This should have enabled a
"navigable" document that allowed readers to jump from the ToC and other
cross-references but I forget the magic incantation to get that working in
the saved PDF version.  References to everything but the examples are live
in the source document but not the PDF.

- ToC now shows three levels.  If you like, the above automation makes it
easy to change this back to two or up to four or five...  Also added a list
of tables.

- correcting the "element structure" figures (6 and 7) to place the "any"
at the start

- used more consistent spelling, formatting, phrases and punctuation throughout

- kept all of the examples, tables and figures together (and with their
captions) on a page -- nothing major should still be split between pages.

thanx,
        doug

[1] http://tinyurl.com/6oy89
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8414/WS-Reliability-2004-08-02-diff.pdf
[2] http://tinyurl.com/54rjp
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8413/WS-Reliability-2004-08-02.pdf
[3] http://tinyurl.com/4ldwa
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8409/ListOfActionItemsAndStatus-2004-08-02.pdf
[4] http://tinyurl.com/4hpke
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8411/ReplyToFixes-2004-08-02.pdf

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.