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]