URI Template: comments on latest draft (Nov 2009)

1) Simple expansion {var}

As described, this seems not so much simple expansion but rather
comma-separated expansion.  To be more consistent with other expansions, can
it be changed to {,var}, and then can we than have a simple {var} that
raises an error condition if var is undefined?  Then '/{foo}/{bar}/{baz}/'
won't expand by default to '////'!

Alternatively, perhaps I should be taking issue with the sentence "If all of
the variables are undefined, then the expression's expansion is the empty
string".  Given that it is possible to provide default values, I would argue
that nothing would be lost if the spec required that at least one variable
was defined for the expansion to succeed.

2) Reserved expansion: {+var}

Would it ever be reasonable to want to do reserved expansion in path-style,
form-style or hierarchical path expansions?

If so, the "+" could be treated here as a modifier to var rather than
thinking of {+var} being a different kind of expansion to {var}, and
permitting {;+var}, {?+var} and {/+var}, also {var1,+var2}.

Modifiers could be another way to address the issue of mandatory/optional
vars.

3) (Proposal) Extension-style expansion {.var}

Particularly if we're going to lose the prefix operator of the old spec
(which is fine), can I put in a plea (again, sorry) for an idiomatic
expansion style for the production of path extensions?  It would reduce by
up to half the number of templates required to describe many applications,
so it seems to me a big win.

Example: if "song" has the value "white-christmas", the expansion for
"{song}{.format}" is "white-christmas.mp3" if "format" has the value "mp3"
but simply "white-christmas" if "format" is undefined/null.


Regards,
Mike
mjb@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake