W3C home > Mailing lists > Public > uri@w3.org > April 2010

URI template: explode modifiers {var*}

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Tue, 6 Apr 2010 09:24:34 +1000
To: "uri@w3.org" <uri@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E11255B806F3@WSMSG3153V.srv.dir.telstra.com>
Thanks for the latest URI template draft (draft-gregorio-uritemplate-04), Roy.
The prose is a pleasure to read, though I have some concerns with the
operators and modifiers.

The explode modifiers ("*" and "+"), defined in section 2.4.1 and 3.4,
are strange (and complicated) beasts.
The intention seems to be to make it easier to include a collection
of values in a URI, by grouping them together under a single variable name.

This doesn't feel like a good approach to me.

Once a variable is defined as holding a collection there is no way
for a template author to select a particular component.

The draft uses 'address' as an example. /mapper{?address*} is expanded to
/mapper?city=Newport%20Beach&state=CA.

What if a particular site decided to host each state's maps using a
per-state domain name (eg http://ca.example.com/mapper?city=...).
This cannot be done once clients are grouping all the address fields under
one variable.
Unfortunately, the decision to use a single 'address' variable may have
been made years earlier, or by another party, such as a standards body.

The explode modifiers provide a choice about how to package items when
defining variables (grouped or individual), but the choice drastically
affects the URI spaces that can be built.
This is bad news when different parties control the URI space
(the template author) and the variables (eg the OpenSearch spec).


Perhaps a different definition of an explode modifier would work:

Treat var* like a wildcard.
Make it shorthand for listing all defined variables with var as a prefix
of their name.
It could even be a bit smart and only select variables that are not selected
more specifically in any other expression in the template.

Example:
 from_zipcode := "1234"
 from_city := "Abc"
 to_zipcode := "9999"
 to_state= "CA"

/mapper{?from*,to*} expands to
/mapper(?from_zipcode=1234&from_city=Abc&to_zipcode=9999&to_state=CA

http://{to_state}.example.com/mapper{?from*,to*} expands to
http://ca.example.com/mapper?from_zipcode=1234&from_city=Abc&to_zipcode=9999


{?*} could be a convenient way of including all the rest of the variables as query params.


--
James Manger

Received on Monday, 5 April 2010 23:25:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC