- 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