W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > September 2004

RE: QA Review on WSDL 2.0 Part 1, Technical comments

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 21 Sep 2004 11:21:29 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA204EFE622@RED-MSG-30.redmond.corp.microsoft.com>
To: Dominique HazaŽl-Massieux <dom@w3.org>, <public-ws-desc-comments@w3.org>

Thanks for your comments.  Our first few resolutions below, more to follow in the coming weeks.  We will assume you accept these resolutions if we don't receive an explicit acknowledgement by 1 October.

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Dominique HazaŽl-Massieux
> Sent: Thursday, August 05, 2004 5:48 PM
> To: public-ws-desc-comments@w3.org
> Subject: QA Review on WSDL 2.0 Part 1, Technical comments

> - the {name} property of the feature and property component uses URIs,
> while all the other {name} properties use QNames; I guess my preference
> would be to have all the {name} properties be URIs, but at the very
> least, I find it confusing to have this inconsistency in the model:
> what's the reasoning behind it? maybe instead of using {name} for those,
> you should use {identifier}?

The WG agreed to rename the {name} property of F&P components to {uri}.

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

> - is there any reason why the {value constraint} in properties
> components (2.8) is represented in XML as an element rather than an
> attribute? given its content model (xs:QName), an attribute would look
> more "natural" (and more in-line with the other representations in WSDL)

Yes, the <property> element contains either a <value> child or a <constraint> child.  The current element syntax supports schema validation by allowing a co-constraint between 'value' and 'constraint', which would be lost if value were an attribute.  The Working Group found schema validation of this co-constraint more valuable than the simplicity of the attribute syntax, and did not approve a change to the spec.

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

> - purely cosmetic: why 'wsdlLocation' as attribute name, rather than
> simply 'Location', since the attribute is namespace qualified (in wsdli:
> ) ?

We modeled wsdlLocation after the xsi:schemaLocation attribute, and a similarity of syntax useful.  The prefix (wsdli) used in our document is only a convention, and the WG felt ns1:wsdlLocation was more self-explanatory than ns1:location when other prefix conventions were used.  The WG did not approve a name change for this attribute.

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

> - C.2 defines fragment identifiers compatible with the XPointer
> Framework; I suspect this means you're defining a new scheme for
> XPointer, in which case this should be said explicitly; also, it would
> probably be wise to mention that at the time of this document, only the
> application/wsdl+xml MIME-type references this scheme as a possible
> xpointer scheme - i.e., I don't think a WSDL resource served as
> application/xml can ben resolved using this XPointer scheme

Not yet resolved.

[See http://www.w3.org/2002/ws/desc/4/lc-issues/#LC6c]
Received on Tuesday, 21 September 2004 18:21:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:31:00 UTC