Re: draft-gregorio-uritemplate-02.txt

Joe Gregorio scripsit:

> > 1. varname is unnecessarily restrictive. There is no harm that I can see
> >    in using the following:
> >
> >    unreservedsansdash  = (alphanum / "." / "_" / "~")
> >    varname             = unreservedsansdash *(unreserved)
> >
> >    For URI Templates, this is *extremely* minor, but for IRI
> >    Templates (see below) this will have a significant impact on
> >    what characters can be used for varname (replace unreserved
> >    with iunreserved)
> 
> That makes sense.

I disagree.  Since variable names are the point where URI Templates meet
the host environment, the set of available names should be those of the
most restrictive (commonly used) host environment, namely those which
match [A-Za-z][A-Za-z0-9]*.

> > 3. For -join, you need to specify what happens if the value is a list.
> >    e.g., foo = ['a','b'] would expand to foo=a&foo=b
> 
> Yeah, I'd like to hear more opinions about using
> lists in operators outside '-listjoin'.

I agree that this is TRT for -join.  For -opt and -neg, it suffices to
say that a list-valued variable is empty iff it contains no elements
(or should it be no non-empty elements?)

> > 4. There are interesting things that could be done if we allow prefix
> >    and append to use list values.  The prefix or postfix would be
> >    applied to each item  in the list. e.g., when foo = ['a','b'],
> >    {-prefix|/|foo} would expand to "/a/b" and {-append|/|foo} would
> >    expand to "a/b/".

[examples snipped]

> I worry about introducing that level of complexity into the
> specification/implementation.

I think this rule meets the Principle of Least Astonishment: like the
other rules, it essentially lifts the operation over the list data
structure.

> > 5. We need to decide whether or not "extension operations" are going to
> >    be allowed, and if so, how are they to be handled.  Should an
> >    template processor signal an error if an unknown operation is used?
> >    Should the processor replace the unknown token with an empty string?
> 
> I am leaning towards a 'must ignore' stance with respect to
> unknown operators, i.e. replace the expansion with the empty string.

I favor a "must die" stance; if an unknown operator is meant, it's better
to throw an exception (or return a distinguished value, where there are
no exceptions) rather than doing what will certainly be the Wrong Thing.

> > 6. We should include a section on IRI Templates. I'll volunteer to write
> >    it up if you'd like.  An IRI template is generally identical to the
> >    URI Template with the exception of the characters allowed in varname,
> >    arg and the replacements.  The following is taken from my expanded
> >    ABNF:
> 
> So in the IRI case any characters outside ( iunreserved / pct-encoded )
> in a variable value need to be percent-encoded, and we skip the UTF-8
> encoding?

I agree here, except in the matter of varnames, as noted above.

Separate issue:  I'd like to see consistent naming for "prefix" and
"append"; either "prefix" and "suffix" or else "prepend" and "append".
I prefer the former pair as more declarative.

-- 
What asininity could I have uttered     John Cowan <cowan@ccil.org>
that they applaud me thus?              http://www.ccil.org/~cowan
        --Phocion, Greek orator

Received on Monday, 26 November 2007 22:38:43 UTC