Re: URI Templates - optional variables?

On 11/08/2007, at 1:39 PM, Mike Schinkel wrote:
> In the abstract, that sounds incredibly complicated.

Well, it's not a simple problem.

> Would the method to invoke this convention be inband (inside the  
> braces) or out of
> band (outside the braces, or worse outside the string?)

Out of band. See <http://www.w3.org/mid/D9FFFFB6- 
F734-48BE-9D39-23541A38F844@mnot.net> for an example that might help  
(indirectly).

> 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
> mean?

That's the other approach that's being discussed. The problem here is  
that there's a potentially large set of such transformation functions  
that you need to identify; I don't have much confidence that we'll be  
able to identify all of the useful functions in one go. For example,  
Roy gives a good start, but we'll also need ways to indicate how to  
handle encoding. And, what if you want to use (for example) a hash-to- 
query-string mapping as well as a particular style of encoding?

As such, I'm suspecting that there'll need to be an answer for  
extensibility here. That means that we can't enumerate all of the  
beginning characters that one has to look out for in template  
variable names; some more general convention is necessary.

> 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."

If you buy into that, why not put all of this type of metadata  
(types, optionality, formatting, encoding, etc.) into the variable  
definition, and leave it out of the variable names altogether?

That's my (somewhat weak) preference.

--
Mark Nottingham     http://www.mnot.net/

Received on Saturday, 11 August 2007 04:26:46 UTC