Re: URI Templates - optional variables?

Am 15.10.2007 um 15:03 schrieb Joe Gregorio:
>> 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.

Fully agree. I think we should define syntax and extensibiliy first  
and talk afterwards about which operations should be in the basic set.

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

If we want templates on the side of a bus, we should do something  
readable and pleasing to the eye. Names are easier to read and  
remember that single char operators.

I would like to write templates such as:

   http://example.org/{x}  ---  substitute x
   http://example.org/{dog(x)}  ---  substitute function "dog"  
applied to x
   http://example.org/{cat(x,y)}  ---  substitute function "cat"  
applied to x and y
   http://example.org/{cat(',',y)}  ---  substitute function "cat"  
applied to literal '#' and y
   http://example.org/{cat(x,dog(y))}  ---  substitute function "cat"  
applied to x and "dog" of y

And would like to have a URI for each function. So, if I GET http:// 
example.org/funcs/dog?{x} I will have the same result as any template  
parser implementing that function does.

And use something like namespace uris for extension functions

   n -> http://example.org/extensions/  --- (where is that done?)
   http://example.org/{n:dog(x)}  ---  substitute function "n:dog"  
applied to x

   which should behave like GET on
   http://example.org/extensions/dog?{x}

As for encoding issues, variable substitutions would always be  
"maximum encoded" and define functions that reverse such encoding.  
Example:
   x = 'a+%2fb/c'
   {x} -> a%2b%252fb%2fc
   {path(x)} -> a%2b%252fb/c
   {raw(x)} -> a+%2fb/c


//Stefan

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

Received on Monday, 15 October 2007 15:42:56 UTC