W3C home > Mailing lists > Public > uri@w3.org > July 2011

Re: uri templates: escaping & defaults

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 14 Jul 2011 19:02:31 -0700
Cc: URI <uri@w3.org>
Message-Id: <729462A0-CE5F-49B4-978B-687E9C369FC2@gbiv.com>
To: Robert Brewer <fumanchu@aminus.org>
On Jul 14, 2011, at 6:18 PM, Roy T. Fielding wrote:

> On Jul 14, 2011, at 6:06 PM, Robert Brewer wrote:
>> Roy T. Fielding wrote:
>>> On Jul 13, 2011, at 9:19 AM, Manger, James H wrote:
>>>> 6.
>>>> There are no examples with defaults for more than 1 variable.
>>>> For example, add "x{/var|1st,empty|2nd}" to section 2.5
>>>> "Value Defaults". The very long list of examples in this
>>>> section is not good sign to me that this feature's design
>>>> is intuitive.
>>> Right.  The reason is simply that the examples get too long.
>>> Anyway, I was thinking about defaults this morning and realized that
>>> I don't have any use case for them.  That is, if we assume that the
>>> server is telling the client what values are to okay to place in the
>>> variables, then why would the server ever tell the client that the
>>> variable is undefined?
>>> The only use case that I know of is that it allows the server to
>>> state what parts of the URI space are never empty.  However, I can't
>>> think of anyone who needs that.  Are there other use cases?
>> I've seen (and written) plenty of API's where /foos/bar/baz makes sense
>> but /foos//baz doesn't make sense (at best, or breaks at worst). It
>> would be useful to be able to write something like /foos/{bar!}/baz
>> where the "!" character constrains the value to be supplied and not
>> empty.
> But that's why we have /foos{/bar}/baz

er, never mind -- that would eliminate "/foos//baz" but not "/foos/baz"

Anyway, the point I was making earlier is that if the client is only using
values that has been given to it by the server, then bar will never
be empty.  I think that is a better solution than a must-be-defined mark
because there is nothing useful that a client can do with a template that
says it is an error.

Received on Friday, 15 July 2011 02:03:02 UTC

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