RE: comments on the wsdl 2.0 working drafts

Thank you for your comments on the WSDL 2.0 spec.  We have resolved each
issue as indicated in-line below.

The latest draft incorporating those fixes is at [1].  If we don't hear
otherwise within two weeks, we will assume these resolutions are
acceptable to you.

[1] http://www.w3.org/TR/2005/WD-wsdl20-20050510/

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Craig Salter
> Sent: Monday, October 04, 2004 7:04 PM
> To: public-ws-desc-comments@w3.org
> Subject: comments on the wsdl 2.0 working drafts
> 
> 
> Here's my thoughts on the working drafts.  In general its an
> improvement over WSDL 1.1 but I still feel a need for simplification.
> 
> Web Services Description Language (WSDL) Version 2.0 Part 1: Core
> Language
> 
> 2.4.1.1 Operation Style
> 
> I think having the interface writer specify the applicable style on an
> interface or operation is a bad approach.  Is the interface writer
> aware of the possible styles that exist?  In addition the style is
> optional, so tools will still need to function in the absence of the
> style attribute.  Furthermore, specifying the style of the interface
> blurs the line between interface and binding.  I think a better
> approach would involve supporting extensible interface/message
> structure constraints via the binding.  Using this approach, when the
> wsdl processor encountered a binding that referenced an interface it
> would utilize the constraints associated with the specific binding to
> validate interface.

Tracked as LC61a [2], the WG didn't agree with your full suggestion, but
did agree to move the styles and RPC signatures section to part 2.  We
felt this addresses the perception concern, that styles are a necessary
part of an interface definition rather than additional metadata that
some code-generating tools might find useful.

[2] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61a

> 2.3 Interface Fault
> 
> Why are fault messages considered 'reusable' but input / output
> messages are not?  This seems inconsistent. A major improvement over
> WSDL 1.1 is the removal of the top level 'message' components.  From
> my experience there's little benefit to specifying 'named' messages.
> If these do exist why are they specified within an interface?  IMHO
> the complexities introduced by named messages outweigh any convenience
> of reuse.

Tracked as LC61b [3], the WG found itself with conflicting comments, to
move faults up (as you did) or to move them farther down [4].  The WG
was unable to reach consensus on either of these approaches and kept the
status quo as a good middle ground.  Rationale on why LC75a was rejected
can be found at [5], some of which might give insight into the LC61b
resolution as well.

[3] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61b
[4] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75a
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0074.html

> 2.5.2 XML Representation of Message Reference Component
> 
> I don't see any use in the inclusion of a 'messageLabel' attribute.
> Are there any examples where this is not redundant (deducible from the
> context)? I think the inclusion of optional attributes/elements in the
> spec that have no clear usefulness is terribly detrimental and one of
> the regrettable weaknesses of wsdl 1.1

Tracked as LC61c [6], the WG reaffirmed the necessity for having the
messageLabel attribute to support extended MEPs (e.g. those not defined
in Part 2).  Our defaulting behavior causes no additional syntactic
overhead for the cases of the MEPs we define.

[6] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61c

> 2.9.2 XML Representation of Binding Component
> 
> Seems odd that the binding lacks infault and outfault.  I'd assume
> that the structures should be symmetric?  These sort of mysterious
> differences make the spec feel clumsy.

Tracked as LC61d [7], the WG agreed to reintroduce these elements,
accepting (along with a few further clarifications) the proposal at [8].

[7] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61d
[8] http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0042.html

> 2.9 Binding
> 
> I'm struck the variety of places where we expect the wsdl author to
> specify binding related information.  An interface has a 'style'
> (though optional).  The binding has a 'type' then there are
> 'extensibility attributes' used to specify a soap protocol.  Then
> there are 'extensibility elements' and of course this does not include
> possible use of 'features' and 'properties'.  IMHO there are too many
> mechanisms at play here.  I'd suggest returning to the simplicity of
> the wsdl 1.1 and its use of the extensibility element.  Here's a
> summary of the constructs I feel should be removed and how ...
> 
> The binding's type attribute.  This could be deduced by the namespace
> of the child extensibility element (e.g. wsdl 1.1).
> The binding's style attribute.  Unneeded .... see comments above on
> 2.4.1.1.
> The binding's extensibility attributes.  Don't encourage their use.
> Why not just utilize the attributes of the extensibility elements
> (e.g. wsdl 1.1).

Tracked as LC61e [9], the WG declined to redesign as you suggest.  We
don't view style as an inherent part of an interface.  The type
attribute specifies the type of binding, which can't be deduced
completely from the attributes.  Extensibility attributes are used to
provide control over parameters of this binding, except where attributes
are inappropriate and elements are used instead.  We already have formal
objections on features and properties which indicates the WG was not
able to come to a complete consensus on this item.

[9] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61e

> Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings
> 
> I don't see any description or examples of how to specify the content
> of a SOAP header?  Is the editor's copy incomplete ... I must confess
> I couldn't make much sense of it.  I think having examples included in
> the Primer would go a long way to making the design clearer.

Tracked as LC61f [10], the WG found this to be a duplicate of LC76d
[11], which the WG agreed to solve by providing a facility for directly
describing SOAP headers in the binding.

[10] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61f
[11] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d

> thanks
> 
> Craig
> 
> Craig Salter
> Rational Studio XML Web Services
> Internet: csalter@ca.ibm.com     Notes: Craig Salter/Toronto/IBM@IBMCA

Received on Friday, 13 May 2005 19:20:22 UTC