RE: Completing Part 1 Appendix C: URI References for WSDL constructs

Thanks for your comments.  We resolved them as detailed below.  If you
don't respond by October 1, we'll assume you accept these resolutions.

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Hugo Haas
> Sent: Tuesday, September 14, 2004 8:58 AM
> To: public-ws-desc-comments@w3.org
> Subject: Completing Part 1 Appendix C: URI References for WSDL
constructs
> 
> Appendix C in Part 1 is not very visible despite being useful, and is
> incomplete.
> 
> First, I believe that we should point to Appendix C every time we talk
> about not being able to a component by a simple QName, such as in
> sections 2.3.1, 2.4.1 and 2.14.1, but there may be others that I have
> missed.

The WG agreed to add links to the Component Designator definition to
sections of specification where we note that QName is insufficient to
identify a component.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC34a]

> Second, section C.2 is lacking references for the following components
> in order for us to fulfill R120, "The description language MUST ensure
> that all conceptual elements in the description of Messages are
> addressable by a URI reference"; I am proposing some solutions:
> - message reference: messageref(interface/operation/direction/label);
> - fault reference: faultref(interface/operation/direction/label/ref);
> - binding fault: bindingfault(binding/ref);
> - binding operation: bindingoperation(binding/ref);
> - binding message reference:
>   bindingmessageref(binding/operation/direction/label).

The WG accepts the proposal in general (though the syntax may change
slightly to remain consistent with other schemes), and also to include
F&P schemes.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC34b]

> Third, some of the construct names in the first column are not
> corresponding exactly to components names:
> - s/operation/interface operation/;
> - s/fault/interface fault/.

The WG agreed to accept the proposal, and will change the names in table
C-1 to match component names.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC34c]

> Finally, I find the the x / y convention hard to read. What about
> something like:
> 
>   endpoint: _endpoint_ being the {name} property of endpoint and
>   _service_ being the {name} property of parent service:
>   endpoint(_service_/_endpoint_)
> 
> with _foo_ being typographically different, e.g. in italic?

The WG agreed with this suggestion, and will also rework the table with
other readability improvements as the new components are added.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC34d]

Received on Tuesday, 21 September 2004 18:21:55 UTC