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

RE: uri templates: escaping & defaults

From: Robert Brewer <fumanchu@aminus.org>
Date: Sat, 16 Jul 2011 10:09:33 -0700
Message-ID: <F1962646D3B64642B7C9A06068EE1E64126D5F38@ex10.hostedexchange.local>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: "URI" <uri@w3.org>
Roy T. Fielding wrote:
> 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.

Draft 05 says "Our expectation is that an application constructing URIs
according to the template will be provided with an appropriate set of
values for the variables being substituted and will be able to cope with
any errors that might occur when the resulting URI is used for name
resolution or access."

Combining that with what you've said above, it seems like you would
expect even a user-agent to show a predetermined set of values to a
user, and not let them supply whatever value(s) they want. But if that's
true, then I can't see how one of the first examples in the spec is
useful to anybody: http://example.com/search{?q,lang}. It's
counterintuitive to see that URL and expect the server to only let me
pick "cat" or "dog" for q. Or are we saying that that's a fine pattern
in query strings, but not path segments?

Machine clients probably wouldn't be able to "do anything useful" when
they can't supply a required value, unless you count "raise an error" as
useful. I'd like that behavior in my clients. User-agents, of course,
could notify the user and ask for a non-empty value.


Robert Brewer
fumanchu@aminus.org
Received on Saturday, 16 July 2011 17:10:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 16 July 2011 17:10:18 GMT