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/