RE: URI Templates - optional variables?

> I think it is critical to limit the potential operations to 
> typical string operations, both for simplicity of 
> implementation and also for our capacity to understand the 
> template without needing to refer to external rules or 
> processing.  There is no reason to have URI templates if we 
> don't limit them to a declarative syntax


> The characters I chose for delimiters are not important.  If 
> we want to avoid URI characters, then Joe's variation is 
> good, though it will make life slightly harder on XML config authors.
> I think the set below is very easy to read, keeping in mind 
> that human language is not universal.
> [snip]
> The main use case for substring substitution is to describe 
> automated resource hierarchies that aren't flat, such as 
> lists of users within a large intranet that are tree-balanced 
> by splitting into sub-collections by the first character of 
> the last name (this is a very common case at my work where 
> thousands of users are often stored within a tree of 
> JCR-based content).  Caches frequently do the same type of 
> content balancing by splitting stored messages by the first 
> few characters in a hash of the URI.  As Mark said, this 
> could be accomplished by external processing of the original 
> variable value, thereby defining a new variable to be used in 
> the template, but then how do we describe such processing to 
> readers of the URI template?  

However, I find all of those examples to be hopelessly obtuse, almost as bad
a regular expressions. See my prior email where I advocated using expansion
directives that are more obvious to a reasonably (but not overly) technical

> IMO, mapping values to 
> identifier string is the whole point of this exercise, so any 
> case that we don't handle within the declarative syntax is 
> the same as punting to javascript.


> One variation that might be worth considering:  If all of the 
> map operators are delimited on both sides by a pipe character, as in
>      {variable}                  = "value"        or "red"
>      {|=red|favoritecolor}       = "value"        or "red"
>      {|<;name=|variable}         = ";name=value"  or ""
>      {|>.html|variable}          = "value.html"   or ""
>      {|+,|name,age,zip,location} = "Fred,41,USA"
>      {|,&|name,age,zip,location} = "name=Fred&age=41&location=USA"
>      {|-0-3|variable}            = "val"          or ""
> then the template processor need only special-case the pipe "|"
> and some people may find that easier to read.  *shrug*

Better, but still not great though it does remind me of Codeblocks in
Clipper[1] hence making it more palatable for me personally. :-0

-Mike Schinkel 


Received on Tuesday, 16 October 2007 04:48:48 UTC