W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2006

Re: CR53: Proposed text for clarification

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Thu, 21 Sep 2006 09:29:47 -0400
To: Philippe Le Hegaret <plh@w3.org>
Cc: Jacek Kopecky <jacek.kopecky@deri.org>, Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-ID: <OFE88F8007.921D509C-ON852571F0.00496DE9-852571F0.004A22D0@ca.ibm.com>
Looks good.

I have a couple of comments.

1. In general I  think we should use keywords, so, e.g. rather than say:

It is an error for
 this element to carry an xs:nil attribute whose value is "true".

say

This element MUST NOT carry an xs:nil attribute whose value is "true".


2. A grammar nit:

Should A xs:anyURI

be An xs:anyURI


Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



Philippe Le Hegaret <plh@w3.org> 
Sent by: www-ws-desc-request@w3.org
09/21/2006 08:17 AM

To
www-ws-desc@w3.org
cc
Roberto Chinnici <roberto.chinnici@sun.com>, Jacek Kopecky 
<jacek.kopecky@deri.org>
Subject
CR53: Proposed text for clarification







From
http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/att-0001/20060629-ws-desc-minutes.html#action02


Change in 6.4.2:

Clarifying what "is combined" means and fixing the wording since a
relative IRI is not longer used in RFC 3986 and its replacement
"relative reference" now contains a fragment.

[[
{http location} OPTIONAL.

 A xs:anyURI, to the Binding Operation component. This IRI is combined
 with the base IRI specified in the {address} property of the Endpoint
 component to form the full IRI for the HTTP request to invoke the
 operation. It MUST contain an absolute or a relative IRI, i.e. it
 MUST NOT include a fragment identifier in the IRI. Input
 serializations may define additional processing rules to be applied
 to the value of {http location} before combining it with the
 {address} property of the endpoint element to form the HTTP request
 IRI. For example, the three serialization formats defined in section
 6.7 Serialization Format of Instance Data define a syntax to use the
 {http location} as a template using elements of the instance data.
]]

should read

[[
{http location} OPTIONAL.

 A xs:anyURI, to the Binding Operation component.  It MUST contain an
 IRI reference and MUST NOT include a fragment identifier
 component. If this IRI is a relative reference, the value of the
 {address} property of the Endpoint component is used as a base uri to
 resolve it, as defined in section 5 of RFC 3986. As a consequence, if
 this IRI is an absolute IRI, the {address} property of the Endpoint
 component is ignored. Input serializations may define additional
 processing rules to be applied to the value of {http location} before
 combining it with the {address} property of the endpoint element to
 form the HTTP request IRI. For example, the three serialization
 formats defined in section 6.7 Serialization Format of Instance Data
 define a syntax to use the {http location} as a template using
 elements of the instance data.
]]

Change in 6.7.1.1

Making it clear that no IRI escaping is performed replacing local
name.

[[

The {http location} property, if present, MAY cite local names of
elements from the instance data of the message to be serialized in
request IRI by enclosing the element name within curly braces
(e.g. "temperature/{town}"):

 When constructing the request IRI, each pair of curly braces (and
 enclosed element name) is replaced by the possibly empty single value
 of the corresponding element. If a local name appears more than once,
 the elements are used in the order they appear in the instance
 data. It is an error for this element to carry an xs:nil attribute
 whose value is "true".
]]

should read

[[
The {http location} property, if present, MAY cite local names of
elements from the instance data of the message to be serialized in
request IRI by enclosing the element name within curly braces
(e.g. "temperature/{town}", see example 6-1):

 When constructing the request IRI, each pair of curly braces (and
 enclosed element name) is replaced by the possibly empty single value
 of the corresponding element. No percent-encoding mechanism, as
 defined in section 2.1 of RFC 3986, is performed on the replacement
 value. If a local name appears more than once, the elements are used
 in the order they appear in the instance data. It is an error for
 this element to carry an xs:nil attribute whose value is "true".
]]

Add the following note at the end of 6.7.1.1 to highlight the
side-effect of this additional processing rule.

[[
Note that this mechanism could be used to indicate the entire abosulte
IRI, including the scheme, host, or port (e.g.
"{scheme}://{host}:{port}/temperature/{town}" or even "{myIRI}").
]]

I don't believe we need to add anything regarding security. The
section 7 of RFC 3986 should be enough.

While I'm at it,

[[
Example 6-2
[...]
GET http://ws.example.com/service1/
    temperature/Fr%C3%A9jus?date=2006-03-27&unit=C HTTP/1.1
Host: ws.example.com
]]

should be fixed. The URI needs to be on one line.

Regards,

Philippe
Received on Thursday, 21 September 2006 13:30:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:41 GMT