[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 unnecessary. 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 values. 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 scan. 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" columns? 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. Regards, 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]