RE: URI templates: comma-separated variable lists

> There are many resources for which {x,y} is the template.

I am sure there are many resources for which {x},{y} is the template,
which isn't ambiguous when one variable is undefined (in contrast to {x,y}).

> In fact, the original server-side imagemaps were map?{x,y}.

I think you are using {x,y} as a shortcut for {x},{y}.
I does save 2 characters, but that is a small a gain for the
ambiguity introduced if not all the variables are defined.


> Likewise, resources in Apache Sling are all name{.selectors*}
> where the selectors are only distinguished by name (not by
> order of appearance in the URI).

That template has 1 variable (selectors) not a comma-separated list so I am not sure how it is relevant to this issue.

If the selectors were explicitly listed the template might be
  "name{.lang}{.fmt}{.ver}"
or
  "name{.lang,fmt,ver}"
Both offer *identical* semantics.
Not allowing the 2nd loses no functionality.
They both only work if all lang values and all fmt values and all ver values are distinct. That is quite a limiting constraint. I don't think we should offer a minor shortcut to template authors that only works under such limitations.
Authors will take the shortcut (eg mimic an example in the spec) and it will bite them when the limitations don't apply to their context.


>> The problem with {alpha,beta,gamma} as a template is that NOTHING
>> (not even a regex) can be used to parse the expansion.

> That simply isn't true.

Ok, it is only true in the general case (when there are no extra constraints on which variables are defined and their values).

Why would an author not use level-1 expressions "{alpha},{beta},{gamma}" instead of a level-3 expression "{alpha,beta,gamma}" when all variables are required? Saving 4 characters is too small a benefit.


Adding a new comma operator {,var} (acting like the . and / operators) would be a more consistent way to cover the corner case where, say, alpha and beta are required but gamma is optional.


>> That should be a huge warning sign that this construct is not useful.

> Or that you have created a paper tiger.  If the values are provided
> by the server, they can be parsed.  If the values are unique, they
> can be parsed.  If the values are never undefined, they can be parsed.
> In short, your argument is false.

Then add a note to the spec saying:
  "The 2-char-per-extra-variable saving that is possible by the allowing a
   comma-separated list of variables MUST only be used when the
   template author is certain that (i) the variable values are provided
   by the server, or (ii) all possible values of all the variables are
   unique, or (iii) the variables are never undefined."

With this text, the shortcut doesn't look so appealing.


> If a server has no use for a given template construct, that construct
will not be published by that server.

True. But it does have to be defined, explained, and illustrated with examples in the spec. It needs to be understood by authors when choosing how to write templates. It needs to be implemented in code. It needs to be handled (and rejected) by tools that automatically convert a template to a regex for parsing where possible.

--
James Manger

Received on Thursday, 25 August 2011 02:50:47 UTC