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

Re: URI Templates - optional variables?

From: Joe Gregorio <joe@bitworking.org>
Date: Mon, 15 Oct 2007 09:03:39 -0400
Message-ID: <3f1451f50710150603v10bba111wcc24bf3f99a3b8ef@mail.gmail.com>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, uri@w3.org

On 10/15/07, Mark Nottingham <mnot@mnot.net> wrote:
> That's what I've been saying all along -- obviously not very well :)
> IIRC, the issue that we never really resolved is invoking the
> template rules; i.e. deciding when to look for and apply the special
> syntax.
> We can come up with a library of rules for different scenarios (good
> start in the other thread, btw), but we'll never be able to cover all
> of the specialist cases. As such, there needs to be a way for a
> template variable to specify additional processing, and for template
> processing engines to be extended.

Additional processing? No. But we can provide a mechanism by which
new operators can be added. There's plenty of room for future extensions,
since every char outside unreserved and !?|'&<> can be used as a new operator.

An alternative to the current proposal is to replace the
single character operators with names, that is:

   {<arg|var}  ->   {?prefix?arg|var}
   {>arg|var}  ->   {?append?arg|var}
   {,arg|var}  ->    {?join?arg|var}
   {&arg|var}  ->   {?joinlist?arg|var}


This makes new operators easier to add and we don't have to
worry about running out of characters.
Of course, that's a very english-centric solution, and
the original proposal has the advantage of being uniformly
cryptic to everyone.

> It's a trade-off, and there are good arguments for both sides; I just
> want to make sure that we make a conscious decision about it. I have
> a feeling that unless someone stands up and yells soon, they'll get
> applied to all templates.

They get applied to all templates.


Joe Gregorio        http://bitworking.org
Received on Monday, 15 October 2007 13:03:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC