RE: URI Templates - optional variables?

John Cowan wrote:
> I'm not sure whether by "template vars" you mean the *names* 
> of variables, or their *content*.  

I mean those things that are inside the braces.  Look at this concrete
though contrived example (since I requested of others, I should do the same
:) 

http://example.com/a{b}c

In my view the parts that should have to follow the URI spec for encoding
are the "http://example.com/a" and "c."   The "b" part is another context
and thus should not have to follow the URI spec for encoding.  Of course the
*value* of a given "b" would need to follow encoding.  Given that, there is
no question about encoding #1 because dashs and letters do not need to be
encoded:

1.) {b}= "-xyz-"
http://example.com/a-xyz-c

However, #2 is a different story as the need to encode the slash is
ambigious:

2.) {b}= "-x/z-"

Is it?: 
http://example.com/a-x/z-c

Or is it?:
http://example.com/a-x%2Fz-c 

OTOH, we could agreed to make any of the following valid values within the
braces ignoring URI ecoding rules assuming an agreed upon decision for
syntax BECAUSE the characters that make up the expansion directives (is that
a good phrase?) that tells the URI Template processor what to substitute in
place of that which is contained within braces inclusive need not be encoded
as the URI needs to be encoded, at least not for any reason I can currently
concieve.  

Note these next examples are only showing character use and not trying to
imply any special type of processing:

http://example.com/a{b:[n]}c
http://example.com/a{x(y)}c
http://example.com/a{h|i|j}c
http://example.com/a{$m}c
http://example.com/a{@s#t}c

Note that I'm not proposing variable names contain anything other than
[A-Za-z0-9_], but that other characters be used for processing directives.
Specifically, I can't see any reason a colon can't be used to denote
something WITHIN THE CONTEXT of that which identifies the location for a
substitution, i.e. within braces.

Of course it is quite possible that I am wrong here as it is hard to prove a
negative. If you believe that I am wrong help me out by providing some
concrete examples where allowing uncoded characters between the braces to be
part of the spec will cause problems that will make it impossible to
implement.

> Given the template "foo/{<bar/|baz}", which can be read "foo 
> slash followed by the value of baz prefixed by bar slash", 
> here are some possible results depending on the value of baz:

That template makes my head hurt. I'm hoping that URI Templates can be made
to be approachable for a broader audience as opposed to a more narrow one.
[Simplicity]==[Liklihood of Adoption] in my book.

I vote for either expansion directives that are borrowed from other well
known sources (such as HTML or JavaScript.) Examples include making things
that act like function calls look like function calls, things that OR use
'|', things that AND use '&', things that index use '[' and ']' and so on. 

Further I argue that we only use characters in contexts that are brain-dead
obvious to a reasonably technical person and if we can't we instead use
words if it is not possible to identify truly obvious characters for
expansion directives (Note: I agree with Nottingham on the use of English.) 

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org

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