RE: draft-gregorio-uritemplate-02.txt

Responses to Mark Nottingham

> I like Joe's syntax, with the exception that having a few special operators for extremely common cases is necessary, I think.
> E.g.,
> http://www.example.com/foo{?arg1&arg2=default&arg3}

> http://www.example.com/bar{;baz;bat=default}


I agree that simpler constructs for common cases are necessary. I suspect that once you define these constructs it will be easier to grok them as abbreviations of a prefix^var*sep^suffix|default syntax, than alternatives to a –op|arg|vars syntax.

 >> More importantly, we need easy support for query parameters where the query name does not match the variable name.

> 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.
[http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_1.1_parameters]
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.

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