RE: Comments on WSDL SOAP Binding Extension section of Adjuncts from WS-Addressing WG

Thanks for your comments.  The WS Description Working Group resolved the
issues as detailed below.

If we don't hear otherwise within two weeks, we will assume these
resolutions satisfy your concern.


> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Katy Warr
> Sent: Monday, September 19, 2005 2:33 PM
> To: public-ws-desc-comments@w3.org
> Subject: Comments on WSDL SOAP Binding Extension section of Adjuncts
> from WS-Addressing WG
> 
> 
> The comments below form part of the the WS-Addressing WG's review of
> the  WSDL drafts (WS-A WG Meeting 19th Sept 05).  These comments refer
> to WSDL SOAP binding Extension section in the Adjuncts document.
> Regards,
> Katy Warr
> 
> WSDL Adjuncts Section: 5.10.3 SOAP Header Block component
> How does wsoap:header indicate required = true/false?
> There does not appear to be a way to indicate that the service
> (a) supports the header and the client may send it
> VS
> (b) supports headers and REQUIRES that the client use the described
> header?
> The mustUnderstand=true attribute part of <wsoap:header> indicates
> only whether the mustUnderstand attribute must be set on the header
> (and not whether it is mandatory for the client to send the header
> itself).

The WS Description Working Group tracked this as a Last Call comment
LC339 [1].  The Working Group agreed to add a 'required' attribute to
wsoap:header and whttp:header similar to wsoap:module, along with a
'required' property in the component model. A missing attribute maps to
'false'. When 'true' it means that the service expects the header to be
there; when 'false' then the sender decides whether it should be there
or not. 

[1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC339


> WSDL Adjuncts Section 5.10.3 SOAP header block component
> The following sentence switches between a SOAP Header Block
> representing 1 header and representing multiple headers.
> "A SOAP Header Block component describes an abstract piece of header
> data (message headers) that is associated with the exchange of
> messages between the communicating parties. The presence of a SOAP
> Header Block component in a WSDL description indicates that the
> service supports headers and MAY require a Web service consumer/client
> that interacts with the service to use the described header. Zero or
> more such headers may be used."

The WS Description Working Group tracked this as a Last Call comment
LC340 [1].  The Working Group agreed to replace "zero or more" with "one
or more", and directed the editors to clean up the use of plurals.

[1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC340

> WSLD Adjuncts Section 5.3 (Default Binding rules)
> Minor comment - comma required after the word 'transmitted' aids
> understanding of this sentence.
> Payload Construction. When formulating the SOAP envelope to be
> transmitted the contents of the payload (i.e., the contents of the
> SOAP Body element information item of the SOAP envelope) MUST be what
> is defined by the corresponding Interface Message Reference component.
>
> WSDL Adjuncts Section 5.10.3 SOAP Header Block component
> "{element} REQUIRED. A xs:QName, a reference to an XML element
> declaration in the {element declarations} property of the Description
> component. This element represents a SOAP header block."
> "This element represents a SOAP Header block" is confusing - it
> refererences the SOAP hdr block representation but doesn't represent
> it itself.

The WS Description Working Group tracked these two items as a Last Call
comment LC341 [1].  The Working Group agreed to add the comma as you
suggest, rename {element} to {element declaration} for consistency with
other property names (and check that this naming convention is adhered
to elsewhere in the document) in order to differentiate the different
uses of "element", and reword the final sentence for more clarity.

[1] http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC341

Received on Wednesday, 5 October 2005 21:05:35 UTC