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

Le mar 21/09/2004 à 20:21, Jonathan Marsh a écrit :
> 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.

I accept all the resolutions below (still waiting for the last one);
thanks for the quick turn around!

Dom

> > -----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]
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org