RE: URI Templates - optional variables?

> For instance, we could have {`ext}, where ext is some 
> extension syntax.

Please let's not use a character like ` that is easily mistake for another
character ' and also very easy for the eye to miss when printed or
displayed. 

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



> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com] 
> Sent: Monday, October 15, 2007 3:47 PM
> To: Mike Schinkel
> Cc: 'Stefan Eissing'; uri@w3.org
> Subject: Re: URI Templates - optional variables?
> 
> I would much rather define a limited core set of <op>'s that 
> cover the most basic and most common cases and include in 
> that set a special <op> code that indicates that the 
> remainder of the token is going to be in some 
> application-specific or extension syntax.
> 
> For instance, we could have {`ext}, where ext is some 
> extension syntax.
> 
> Examples:
>   {`func(var,stuff)}
>   {`http://example.org/foo}
> 
> Note that the {`ext} only differs from {var} in that the 
> application would be expected to perform some kind of 
> evaluation of ext as opposed to var which is effectively just a key.
> 
> e.g., {foo}  -> map["foo"]
>       {`foo} -> eval("foo")
> 
> We could also allow for something like {`{arg}|{ext}}, where 
> {arg} is inserted if ext evaluates to a null value or an empty list.
> 
> e.g., {`bar|foo} -> eval("foo") || "bar"
> 
> - James
> 
> Mike Schinkel wrote:
> > 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-fo
> > r-webf
> > orms-2/
> > http://lists.w3.org/Archives/Public/uri/2006Dec/0028.html
> >

Received on Monday, 15 October 2007 20:00:32 UTC