RE: URI Templates - optional variables?

Mark Nottingham wrote:
> By default, a template processor doesn't invoke the code to 
> process this type of convention, in this approach.
> Instead, a template author has to nominate their use 
> explicitly; e.g.  
> a template variable definition may say "the foo convention is 
> applied to the bar variable." Then, that code that implements 
> that processing needs to be turned on, by some 
> as-yet-undefined mechanism. If somebody ever comes up with a 
> template variable definition language, it might be through 
> that; otherwise, it's probably API-specific.
> This is alluded to in section 3.3 of the current draft. As I 
> said before, it's just one way forward. I'm not against 
> others, as long as
> a) they don't make URI templates appreciably more complex to 
> use in the default case (there's a fair amount of mindshare 
> behind just using "{bar}/baz" in 
> documentation), and b) they don't profile or otherwise 
> restrict the set of URIs you're able to template.

In the abstract, that sounds incredibly complicated.  Maybe it would be much
simplier in implementation, but I don't see it from your description.  Would
the method to invoke this convention be inband (inside the braces) or out of
band (outside the braces, or worse outside the string?)  Wouldn't it be
easier to simply say something like "If it starts with a single specific
indicator character (colon, equal sign, other?) (i.e. '{:xxxxxx}',
'{=xxxxxx}') then past that character for formating info, otherwise not. And
parsers can choose not to support the extension."  Or maybe that's what you

That said, I do think you planted a seed for an excellent idea, and that is
to define a "template variable definition language" that is separate from
URI Template.  That could mean we split the current spec in two and assign
basic templates as per the 1.1 URI Template spec to be TVDL 1.0 after which
we can immediately start working on TVDL 1.1.  That would certain follow the
principle of "separation of concerns."


-Mike Schinkel -

Received on Saturday, 11 August 2007 03:39:43 UTC