- From: Jonathan Marsh <jonathan@wso2.com>
- Date: Thu, 15 Feb 2007 17:05:26 -0800
- To: "'Jean-Jacques Moreau'" <jean-jacques.moreau@crf.canon.fr>
- Cc: <www-ws-desc@w3.org>
Wow, thanks for the awesome amount of work! I've been looking at it closely all afternoon ;-) A few nits and questions: ---------- 5.1: on operation: whttp:contentCodingDefault="xs:string"?? > whttp:queryParameterSeparator="xs:string"? Remove the extra ">", and I think add a second question mark to the latter. ---------- 6.2 on input and output: whttp:contentCoding="xs:string? > Missing terminating quotation. ---------- RE CR143, should it be whttp:contentCoding or whttp:contentEncoding? I assumed (and implemented in the test suite) that we'd parallel as closely as possible the HTTP Content-Encoding header. One or the other needs to change... ---------- Re CR087, if no content encoding is specified, or if an empty value is specified, a Content-Encoding header with an empty value is inserted. Is this what we want or can empty Content-Encoding headers be omitted? My reading of http://www.ietf.org/rfc/rfc2616.txt is that an empty value isn't permitted. A fairly intrusive rewording of 6.4.2 would be necessary to reflect this. 6.4.2 HTTP Content Coding Selection When formulating the HTTP message to be transmitted, content encoding for a given Binding Message Reference component is determined as follows: - If the {http content coding} property has a non-empty value, a Content-Encoding header-field MUST be inserted with the value of this property. - Otherwise, if the value of the parent Binding Operation component's {http content coding default} property has a non-empty value, a Content-Encoding header-field MUST be inserted with the value of this property. - Otherwise, if the value of the grandparent Binding component's {http content coding default} property has a non-empty value, a Content-Encoding header-field MUST be inserted with the value of this property. When formulating the HTTP fault message to be transmitted, content Encoding for a given Binding Fault component is determined as follows: - If the {http content coding} property has a non-empty value, then a Content-Encoding header-field MUST be inserted with the value of this property. - Otherwise, if the parent Binding component's {http content coding default} has a non-empty value, then a Content-Encoding header-field MUST be inserted with the value of this property. The body of the response message is encoded using the specified content encoding. ---------- Re CR109, the 5 soap codes are prescribed by the spec, but no assertion markup is provided as the issue resolution requested. Changing "are" to "MUST be" and adding assertion markup would complete this item. ---------- Re CR110, the wording is slightly awkward and doesn't completely address the issue. I'd suggest replacing "can indicate whether" with "indicates whether" or "can indicate that". ---------- 6.8.1.1 "abosulte" ->"absolute" ---------- Re CR120, can you point me to where the fix has been made? I can't find it where I expected it - the second sentence of 6.8.2. ---------- Re CR124, I still can find "features and properties" once in the doc. I assume you didn't check in the fixes as the doc date is a week old? The other issues listed at part 1, plus CR132, don't seem present. ---------- Re CR139, the word "network service" still appears in the intro. Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com > -----Original Message----- > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On > Behalf Of Jean-Jacques Moreau > Sent: Thursday, February 15, 2007 3:07 AM > To: WSD Public > Subject: Status: Editorial action items > > > For the hurried reader, I'll start with the editorial AI that are still > outstanding after the last round of editing: > > - CR136 > - CR138 > - CR145 > > Here are the resolutions that I've implemented: > > Part 1: > - CR124 > - CR125 > - CR126 > - CR128 > > Part 2: > > - CR044 > - CR053 > - CR067 > - CR084 > - CR087 > - CR091 (by Philippe) > - CR092 > - CR109 > - CR110 > - CR111 > - CR113 > - CR114 > - CR116 > - CR117 > - CR119 > - CR120 > - CR123 > - CR130 > - CR132 > - CR133 > - CR137 > - CR139 > - CR143 > - CR144 > - CR146
Received on Friday, 16 February 2007 01:05:33 UTC