W3C home > Mailing lists > Public > uri@w3.org > October 2007

RE: URI Templates - optional variables?

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Tue, 16 Oct 2007 00:48:32 -0400
To: "'Roy T. Fielding'" <fielding@gbiv.com>
Cc: "'URI'" <uri@w3.org>
Message-ID: <010b01c80faf$d0d0fdf0$0702a8c0@Guides.local>

> 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

+1

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

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

+1 

> 
> 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
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org 

[1]
http://www.mikeschinkel.com/blog/anonymousmethodsinc20whatsoldisnewagain/
Received on Tuesday, 16 October 2007 04:48:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:37 GMT