Review of URI Template draft #3 / was Re: URI Templates: done or dead?

DeWitt Clinton wrote:
> I personally agree that it is a little too complex, for the same reasons
> you suggest, Mark.  But if no one expresses interest in doing another
> iteration on the spec, then I'd still be +1 on shipping it as is rather
> than dropping it altogether.

Sorry for jumping in so late.  I just had a quick review of
URI Template draft #3.  Here are my comments and questions.
I'm aware there might be reasons for the draft's status quo.

  1.  In 4.2. (Template Expansions) the given grammar reads
        vars        = var [ *("," var) ]       .
      I would have expected either
        vars        = var [ 1*("," var) ]      or
        vars        = var *("," var)
      instead.  Is this an intended choice?

  2.  The draft does not mention case sensitivity of
      variables names.  Does "FOO" match "foo"? Is this
      left to an implementation?

  3.  I find the operators <opt> and <neg> quite unnatural.
      Is there a difference between {k=v} and {-opt|v|k}?
      Does <opt> served more than complementing <neg>?
      Does <neg> have practical applications?
      Also, <opt> and <neg> reminded my or Lua's use of
      the <and> and <or> operators but I'm not sure if that
      would be a good trade for everybody.
      Maybe <first> and <second>?

  4.  The operators <list> and <join> feel quite similar to me.
      I think <pairs> would be a better name for <join>,
      and <list> is the real <join>.  So let me propose this
      translation:

        {-list|,|l}   --> {-join|,|l}
        {-join|&|a,b} --> {-pairs|&|a,b}

  5.  I'm wondering if it would be good idea to hard-code
      the allowed operator names into the grammar.
      Instead of
        op          = 1*ALPHA
      that would make
        op          = "opt"|"neg"|"prefix"|"suffix"|"join"|"list"
      Is adding custom operators allowed?  If not it might
      be asking for it.  Was this defined with a parser in mind?

      Taking this idea a step further it would allow us to
      embed the list-operator-takes-exactly-one-var constraint
      into the grammar, e.g. though rules like
        op          = "opt"|"neg"|"prefix"|"suffix"|"join"
        operator    = "-" ((op "|" arg "|" vars)
                          | ("list" "|" arg "|" var))

  6.  I'm a bit confused of the different use of '/': While
      a slash in the argument makes it through unescaped in

        bar := ["fee", "fi", "fo", "fum"]
        "{-prefix|/|bar}"
        -> "/fee/fi/fo/fum"

      it is escaped in

        garply := a/b/c
        "http://example.org/{bar}{bar}/{garply}"
        -> "http://example.org/fredfred/a%2Fb%2Fc"   .

      So the argument in {-<op>|<arg>|<vars>} is never escaped?
      Which characters must be escaped when substituting a variable?

  7.  Questions related to RFC 3986:
      - Can a brace block span several parts of a URI?
        - If so is it discouraged or does it come with problems?
      - Are brace blocks ("{".."}") allowed in any part of a URI?
        - If so does it come with problems?
      - Maybe hint that '{', '}' and '|' are not in URIs and
        that URI templates are not valid URIs itself before
        substitution.

  8.  References to other RFCs are done inconsistently, for instance
      in 6. (IANA Considerations) it reads
        "In common with RFC3986[..]"
      but later
        "[..]defined in [RFC4395]".

  9.  Why is variable plugh evaluated like this
        plugh := ["\u017F\u0307", "\u0073\u0307"]
        "{-suffix|:|plugh}"
        -> "%E1%B9%A1:%E1%B9%A1:"
      in 4.5. (Examples)?

 10.  I guess people will use their own words for "{".."}" blocks
      unless there is a term ready to use.  Is there any?
      I used brace blocks above.  Curly blocks?  Template field?


> Even in its current form it is quite
> useful, and I'd be comfortable implementing it as it stands.

What language will your implementation be written in?



Sebastian

Received on Monday, 15 September 2008 17:12:05 UTC