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

Re: URI Template experience

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 26 Feb 2010 18:22:56 -0800
Cc: URI <uri@w3.org>
Message-Id: <20B5D3E8-CB0B-4CC2-98FC-DD8DB3E9DC3D@gbiv.com>
To: mjb@asplake.co.uk
On Feb 25, 2010, at 11:53 PM, Mike Burrows wrote:

> Um, don't the values come from the client?  As the spec stands the client has no clue about which variables are mandatory and which are optional.  To be honest though, I can live without this as I already hold externally the information on whether variables are mandatory or optional.  I won't mention it again, but it does still seem to me sensible change to make though.

The client can't invent values out of thin air, or at least if they
do so then the only way to know what the result should be is to
check with the server.  The context of use (e.g, WADL) can also
limit them to specific valid values or define the value constraints
(like variable types) for the client to check.

In general, there are no mandatory variables because there are no
invalid IRI references (unless the server says so).
E.g., the path//path examples you gave are not inherently invalid
even if this template says they are not, since there is no guarantee
that the template reflects all valid names within that server space.

> Sorry, one last thing.  Not that I have a use case for reserved expansion, but should it allow {var,+hello}, i.e it works as a per-variable modifier?   Achieving reliable comma-separation in the presence of optional variables would be difficult otherwise.

I would think that the way to achieve reliable comma separation is
to not allow commas in the values when using reserved substitution,
since that can be enforced by whatever is providing the values.

>  And it is understood that there are significant limits to what default values could be specified for reserved expansion (I assume they're allowed, though there are no examples)?

Reserved characters are not currently allowed in defaults, though
I was tempted to allow '=' for the empty keys case.  Perhaps we
could make an unrestricted default for use only within reserved
expansions, but that would make the grammar ambiguous.

I think the reason we are avoiding reserved insertion is because
almost everyone does it wrong if given the chance.  The only use
cases I know of where it works well, and is really necessary, are
for the beginning of a reference (for substituting a base URI
to make all references absolute) and at the end of a reference
(for passing another URI at the path end or within a query).

I don't know of any other common use cases that aren't already
handled by the various operator delimiters.   Let me know if you
think of one.

Received on Saturday, 27 February 2010 02:23:25 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:53 UTC