RE: LC45: {http location} sometimes a template, sometimes not

I don't quite get how 1a is crisper.  Seems like 2) is the way to go for
me.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Hugo Haas
> Sent: Wednesday, September 29, 2004 2:04 AM
> To: www-ws-desc@w3.org
> Subject: LC45: {http location} sometimes a template, sometimes not
> 
> All,
> 
> I took an action item last week to start a discussion on the nature
> and use of the {http location} property.
> 
> The HTTP binding defines the {http location} as a binding operation
> property to specify a per-operation request URI, with the endpoint
> address as the base URI to construct it.
> 
> The issue is that, while the application/xml and multipart/form-data
> serializations, as well as probably most other serializations that
> people will come up with, use this property as a plain URI, the
> application/x-www-form-urlencoded serialization uses the value of this
> property as a template to form a URI.
> 
> In other words, we have:
> 
> - for application/xml and multipart/form-data:
> 
>   Request URI = base({http location}, {address})
> 
> - for application/x-www-form-urlencoded:
> 
>   Request URI = base(template({http location}), {address})
> 
> where:
> - base(U1, U2) computes a URI with using U1 as relative to U2
> - template(T) computes a URI based on a template T.
> 
> Our text says that {http location} is always a template, which isn't
> correct as shown above. Nor is it always a standard URI. It's a
> property that basically has two different types for now, and this
> isn't very well stated.
> 
> After having thought about this a little, we have three possibilities:
> 
> 1. introduce a new property, {http location template}:
> 
>   a. and use the whttp:location attribute to set both {http location}
>      and {http location template}; we could then say that we always
>      have:
> 
>        Request URI = base({http location}, {address})
> 
>      but also that a serialization might define:
> 
>        {http location} = template({http location template})
> 
>      with its own syntax, i.e. its own template() function.
> 
>   b. and introduce a new attribute whttp:locationTemplate in the XML
>      serialization to specify {http location template}; the drawback
>      is that it is going to complicate the binding as sometimes
>      whttp:locationTemplate will have to be used, and other times
>      whttp:location will be the one which is relevant, which is going
>      to be confusing.
> 
> 2. make it clear that {http location} can be either a URI template or
>    a normal URI, and that the way it is interpreted to construct the
>    HTTP Request URI is defined by the input serialization.
> 
> (2) is basically the same as (1a), except that we are not being as
> rigorous. (1b) is going to be too messy IMO.
> 
> Here is what (1a) would entail:
> 
> - modify the properties on the binding operation:
> 
>   {http location}
> 
>     A wsdls:anyURI. This URI is combined with the base URI specified
>     in the {address} property of the endpoint element to form the full
>     URI for the HTTP request to invoke the operation. It MUST contain
>     an absolute or a relative URI, i.e. it MUST NOT include a fragment
>     identifier in the URI.
> 
>   {http location template}
> 
>     A wsdls:anyURI. This is a template following the URI syntax which
>     may be used by a particular input serialization to generate the
>     value of the {http location}. The syntax of the template as well
>     as the rules to generate {http location} are defined by the
>     serialization. It MUST contain an absolute or a relative URI, i.e.
>     it MUST NOT include a fragment identifier in the URI.
> 
> - modify the XML mapping, by saying that whttp:location maps to both
>   {http location} and {http location template}.
> 
> - rewrite '3.8.1 Serialization as "application/x-www-form-urlencoded"'
>   to talk about computing the value of {http location} from {http
>   location template} with our syntax.
> 
> I think that (2) would basically mean:
> 
> - clarifying {http location}
> 
>   {http location}
> 
>     A wsdls:anyURI. This URI is combined with the base URI specified
>     in the {address} property of the endpoint element to form the full
>     URI for the HTTP request to invoke the operation. It MUST contain
>     an absolute or a relative URI, i.e. it MUST NOT include a fragment
>     identifier in the URI. 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 URI. For example, the
>     application/x-www-form-urlencoded serialization defined in section
>     3.8.1 defines a syntax to use the {http location} as a template
>     using element of the instance data.
> 
> - clarifying 3.8.1 Serialization as
>   "application/x-www-form-urlencoded" to indicate that the rules we
>   describe are for template({http location}) which need to be used as
>   explained in the description of {http location} as described above.
> 
> So (1a) is crisper, but (2) is simpler.
> 
> Comments?
> 
> Regards,
> 
> Hugo
> 
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Thursday, 30 September 2004 08:01:08 UTC