Re: Status: Editorial action items

Jonathan,

Thanks for your kind words and careful reading.

I've implemented some of your suggested fixes and do have some further 
questions.

I will look at your other items next week, probably Wednesday.

JJ.

Jonathan Marsh wrote:
> 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"?? >
> Remove the extra ">",
DONE (for all occurrences in the SOAP binding)
QUESTION: shouldn't we do this in the HTTP binding as well?
>   whttp:queryParameterSeparator="xs:string"?
>  and I think add a second question mark to the latter.
>   
DONE (in the SOAP binding)
QUESTION: same as above.
> ----------
> 6.2 on input and output:
>   whttp:contentCoding="xs:string? >
> Missing terminating quotation.
>   
DONE (for all occurrences)
> ----------
> 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...
>   
The other ;-)

I've looked at the HTTP/1.1 spec before implementing the resolution. The 
attribute is indeed called "Content-Encoding", but the functionality is 
simply named "content coding". I've used the latter terminology.
> ----------
> 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.
>   
DONE
> ----------
>
> 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".
>   
DONE. I've reworded as follows:

"The {http cookies} property allows Binding components to indicate that 
HTTP cookies (as defined by RFC2965) are used by specific operations of 
the interface that this binding applies to."
> ----------
> 6.8.1.1 "abosulte" ->"absolute"
>   
DONE
> ----------
> 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.
>   
I thought I had done that... Ah! I had fixed the Abstract, not the Intro!

DONE:
- fixed the intro (copied from Part 1)
- moved the dependency on Part 1 from Abstract to Intro (where it belongs)
- removed ultimate paragraph since Part 1 is already described in the 
1st paragraph
- removed the referenced to the Primer since we don't do that in Part 1
- updated the Intro in Part 1 to have an uptodate description of Part 2

JJ.
> 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 12:00:07 UTC