- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 9 Mar 2005 13:18:58 -0800
- To: <public-ws-addressing@w3.org>
1) See my Core comment which applies here too. > The Short Table of Contents does not provide significant value over > the complete version since the complete version fits easily on a > single screen with room to spare. I assume this is automatically > generated by the build process. Can we drop the Short Version? 2) Section 2.3 is titled "State Machine" but there's no further mention of states or machines. Can the title be changed to something more meaningful? 3) Section 2.4 has an error in the SOAP Action URI - should be "http://www.w3.org/2003/05/soap/features/action/". 4) The title of the SOAP 1.2 Addressing 1.0 Feature is not consistent throughout the document. There are occurrences of SOAP 1.2 Addressing Feature and Web Services Addressing 1.0 Feature elsewhere in the document. Personally, I'd drop the 1.0, it is just too awkward. Future features could be called SOAP 1.2 Addressing Feature 2.0 or something like that. 5) Example 3-2 implies (subtly) that wsa:Action is not required. It would be better to show the message with a wsa:Action header. Or note in the text that other wsa:* headers will/may also appear. 6) Section 4.2 Second sentence appears to have a "," instead of a ";" or other stronger punctuation. 7) Section 5 says: "The [action] property below designates WS-Addressing fault messages: http://www.w3.org/@@@@/@@/addressing/fault". But as we're (unfortunately) not defining that URI we should illustrate a different [action] value. 8) Section 5.2 lists as required (in certain circumstances) headers of To, MessageID, and Action. These should be MessageID, RelatesTo, and Action, I think. 9) Section 5 mixes property notation such as [message id] and element names such as MessageID. Please consistently use property notation. 10) Section 5.5 ed note - second sentence grammar needs tweaking. 11) See my Core comment which applies here too: > 6) Many sections and subsections don't have explicit ids (e.g. > Security Considerations). It's nice to have readable IDs for linking > to the spec with fragments.
Received on Wednesday, 9 March 2005 21:19:33 UTC