Re: draft-gregorio-uritemplate-02.txt

On 17/01/2008, at 12:13 PM, Manger, James H wrote:

> > Not sure I agree here; if we're going to add a layer of  
> abstraction, let's have a good reason for it.
> Example:
> OpenSearch (1.1) defines 7 parameters (variable names): searchTerms,  
> count, startIndex, startPage, language, inputEncoding, and  
> outputEncoding.
> [ 
> ]
> The examples in the OpenSearch spec that use these in query  
> parameters all use different query names. For instance, …? 
> q={searchTerms}&pw={startPage}.
> Many web site search interfaces use different name for the  
> OpenSearch parameters: “q” or “query” for “searchTerms” is common;  
> “oe” for “outputEncoding”; “page” for “startPage” etc.
> Specifications (such as OpenSearch) will often define the variable  
> names, while web sites define their own query names. Consequently,  
> the variable and query name will often not match. Consequently,  
> templates need to support this easily, which {-join|arg|vars} does  
> not do.

Sounds good. I wasn't thinking about standard-defined templates...

> >> The simplest model is to say each variable value is a list of  
> (Unicode) strings. An empty list is treated as if the variable was  
> undefined.
> > Not sure I'm with you here.
> If some variables are strings (x="Hi") and some are lists of strings  
> (y=["red", "blue"]), it is simpler to say all variables are lists of  
> strings (it is just many lists will only contain 1 string). A string  
> in a programming language can have a value (0, 1 or more characters)  
> or be undefined (eg null). A list of strings has an extra  
> possibility: it can be an empty list. Consequently, the spec needs  
> an explicit statement that a variable whose value is an empty list  
> is treated the same as a variable whose value is undefined (both of  
> which are different from a variable whose value is a list of 1 empty  
> string).
> x=["Hi"]
> y=["red", "blue"]
> z=[""]      non-empty list, with 1 string that has no characters
> w=[ ]        empty list
> z and w are different. v is not defined.
> “A{-prefix|_|z}B{-prefix|_|w}C{-prefix|_|v}D” would become “A_BCD”)

Seems reasonable, but I suspect that however we describe the data  
model, there's going to be about the same amount of verbiage around it.


Mark Nottingham

Received on Monday, 28 January 2008 00:10:54 UTC