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