RE: URI Templates - optional variables?

It is funny how we keep going full circle.

I'll throw my earlier suggestions to use a name and colon where the default
is just {var}:

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

Also for functions where functions could be defined by external
extensibility mechanism (i.e. functions in Python):

	{func(var,stuff)} 

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

While I greatly see the necessity of having standardized mechanisms for
identifying variables and functions, I think they should be seperated from
the URI template spec as the URI template spec defines a single string and
not the context in which that string operates.

Better to define how URI Templates can be used in contexts, for example in
WebForms
http://blog.welldesignedurls.org/2007/01/11/proposing-uri-templates-for-webf
orms-2/
http://lists.w3.org/Archives/Public/uri/2006Dec/0028.html

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


> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> Behalf Of Stefan Eissing
> Sent: Monday, October 15, 2007 11:43 AM
> To: Joe Gregorio
> Cc: Mark Nottingham; Roy T. Fielding; uri@w3.org
> Subject: 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 17:55:25 UTC