Re: URI Templates - optional variables?

Mike Schinkel scripsit:

> Forgive me if I'm not seeing it correctly but why would template vars (i.e.
> the stuff inside braces) need to follow the same rules are URIs?  As far as
> I understand, a URI Template is not a URI, it is a new entity specifically
> designed to allow the creation of URIs.  Requiring URI Template *variables*
> to follow the encoding rules for URI seems to me to invite tremendous
> complexity where I don't currently see it being needed.

I'm not sure whether by "template vars" you mean the *names* of variables,
or their *content*.  I assume that variable *names* are just alphanumeric,
a subset of URI unreserved characters.  The value of a variable can be
any sequence of characters: when the value of a variable is inserted into
the result URI, all characters are UTF-8-encoded and then %-escaped with
the exception of unreserved characters.  (The unreserved characters are
the letters, digits, hyphen, period, underscore, and tilde.)

In Joe's proposal, a template can only contain URI-characters, plus
"{" to mark the start of an expansion, "|" to separate the parts of
an expansion, and "}" to mark the end of an expansion.  This makes the
template very simple to parse, as you don't have to worry about any of
"{", "|", or "}" being anything but an expansion.

So if you want an unreserved character, it can be directly in the template
or in the value of a variable.  If you want a reserved character, it
must be directly in the template, either outside an expansion or in the
"stuff" part of an expansion.  If you want a non-URI character, it must
be in the value of a variable, or else you can UTF-8-encode and %-escape
it yourself and put it in the template.

> If I'm wrong on this point can you please explain why, and also give
> concrete examples as I'm not so good in visualizing things when only
> discussed in the abstract.

Given the template "foo/{<bar/|baz}", which can be read "foo slash
followed by the value of baz prefixed by bar slash", here are some
possible results depending on the value of baz:

if baz is null/undefined, you get "foo/" (slash inserted from template)
if baz is the empty string, you get "foo/bar/" (second slash is from expansion);
if baz is the string "toto", you get "foo/bar/toto";
if baz is the string "toto/tutu", you get "foo/bar/baz/toto%2Ftutu"
        (slash in variable value is escaped).

> > You can't put the var first because there may be multiple vars.
> 
> But there are also multiple potential args, so that argument doesn't
> fly, right?

Yes, my bad.  I should have said that you can put the stuff and the var(s)
in either order, but you must use a delimiter character that can't appear
in either.  The simplest way to achieve that is to use a character that
can't appear in a URI at all, such as "|".

-- 
John Cowan  cowan@ccil.org    http://ccil.org/~cowan
Big as a house, much bigger than a house, it looked to [Sam], a grey-clad
moving hill.  Fear and wonder, maybe, enlarged him in the hobbit's eyes,
but the Mumak of Harad was indeed a beast of vast bulk, and the like of him
does not walk now in Middle-earth; his kin that live still in latter days are
but memories of his girth and his majesty.  --"Of Herbs and Stewed Rabbit"

Received on Monday, 15 October 2007 23:14:05 UTC