RE: [wsrm] About MP8

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

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.