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 12:29:51 UTC