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: Editorial comments on 0.993

Section 1.1, Purpose of WS-Reliability

Line 74

Change "The purpose of WS-Reliability is to address reliable messaging
requirements, which become critical" to "WS-Reliability addresses
reliable messaging requirements, which are critical".

Line 77

Change "This specification is intended as an initial proposal for
defining reliability" to "This proposal defines reliability".

Section 1.2, Scope and Definition of Reliable Messaging

Line 81

Change to "This specification focuses on the SOAP layer and
envelope. It defines reliable messaging as the mechanism supporting
any of the following requirements:".

Line 88

Change to "Within this scope, this specification supports:".

Line 92

Change to "Some features are out of scope of this specification, yet
this design is compatible with their implementation.  They are:".

Section 1.3, Notational Conventions

Lines 121-127

The formatting on this list doesn't make it very clear.  Should it be
redone as a table?

Line 122

Change "e.g." to "E.g.,".

Line 128

Add the namespaces from the similar table in Appendix A and remove the
table in Appendix A.

Section 1.5, Examples of Messages Compliant with WS-Reliablity

Remove the "xmlns:xlink", "xmlns:xsi", and "xsi:schemaLocation"
namespace declarations and attributes from the examples since they are

Remove the XML Declarations since they are unnecessary.

Line 178

Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" to
properly use the "example.org" example domain name.

Lines 182-183

Change "No Duplicate Delivery" to "Duplicate Elimination" and change
"Ordered Delivery" to "Guaranteed Message Ordering" to match the terms
used in line 90.

Lines 239-242

The explanation should also explain the NonSequenceReply element.

Lines 229, 260, 262

Use 'straight' quotes instead of 'smart' quotes around attribute

Section 1.6, Terminology

Line 283

Change "e.g," to "e.g.,".

Line 288, 304

Why must the time be identifiable?  Why is it not sufficient to
just preserve the order of submissions, e.g., in a queue?

Line 292

Move to the next page (i.e., keep it with the following paragraph).

Line 294

Change "Reliablity feature" to "reliability features".

Line 297

Remove "A Message Identifier is".  Remove the comma after "header".

Line 302

Remove "Message delivery is".  Change "deliver" to "Deliver".

Line 304

Change "(application)" to "(e.g., the application)".

Line 316, 317, 319

"Acknowledgment messages" are not defined.  There are now only
"Acknowledgment indications".

Line 329

How can a "Reliable Messaging Fault Indication" signal a failure to
receive a message when this specification "expects that the transport
layer will not deliver a corrupted message" (line 1308) and there are
no fault codes for non-delivery of messages?

Line 336

A reply may now include multiple Acknowledgment Indications.

Line 340

Remove one of the spaces in "in  a".

Line 353

Make the sentence begining "This polling pattern is generally
expected..." into a note following the definition since this sentence
is more a comment than a definition.

Line 355

Change "behind the firewall cases" to "e.g., when behind a firewall".

Lines 297 to 356

Reorder the definitions to reduce the forward references:

Message Identifier
Duplicate Message
Message Delivery
Reliable Message
Acknowledgment Indication
Acknowledgment Message (new definition)
Reliable Messaging Fault Indication
Reliable Messaging Reply
Response RM-Reply Pattern
Callback RM-Reply Pattern
Polling RM-Reply Pattern
PollRequest Message

Section 1.7, The Reliability agreement

Line 357

Change "agreement" to "Agreement" to match the capitalization style of
similar headings.

Line 362

Change "notify operations on" to "and notify operations at".

Line 366

"between the application layer, the sender and receiver RMPs" does not

Section 1.7.2, RM Agreement Items

Line 388, 390, 392

Change "period" to "period.".

Lines 388-406

Should this list be a table with "Name", "Value", and "Definition"

Section 1.7.3, Messaging Scope of Agreement Items

Line 415

Change "is affecting" to "affects".

Section 2, Messaging Model

Line 450

Change "message" to "messages" twice.

Line 458

Change to "The three ways to send back an Acknowledgment message or a
Fault message are as follows:".

Line 461, 467, 474

Remove "With this message reply pattern,".

Line 463

Change "The figure 1" to "Figure 1".

Line 468

Change ")," to ")".

Line 469

Change "The figure 2" to "Figure 2".

Line 488, 491

Change "In case" to "When".

Section 3, Reliability Features

Line 499

"Business payload" is undefined.

Section 5, Operation Aspects and Semantics

Line 1263

Number the table and make this the title for the table.

Line 1271

Why are "Supported" and "Disallowed" so large?

Appendix A

Line 1604

Change the section numbers to "A.1.", etc.

Line 1605

Add a space after ")".

Line 1606

Change "supported/required" to "supported or required".

Line 1628

Merge this section into Section 1.3.


Tony Graham
Web Products, Technologies and Standards           Phone: +353 1 8199708
Sun Microsystems                                              x(70)19708
East Point Business Park, Dublin 3, Ireland

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