RE: Status: Editorial action items

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