Re: uri templates: escaping & defaults

On Jul 13, 2011, at 9:19 AM, Manger, James H wrote:

> A couple of comments on escaping and defaults in <draft-gregorio-uritemplate-05>.
> 
> 2. (being really picky)
> Append "or a percent character" to the last sentence of section 1.1 "Overview" since "%" has a special function in URIs but isn't actually in the reserved set.
> 
>    ... the result of template processing can be rendered as an
>  IRI by transforming each of the pct-encoded sequences to their
>  corresponding Unicode character if that character is not in the
>  reserved set or a percent character.

Ah, yes, thanks.

> 3.
> Section 2 "Syntax" (3rd paragraph) says a pct-encoded char within a template is decoded before further processing unless the char is in the reserved set.
> This is not quite right. For instance, a literal part of a template can legitimately include "%7B" (since a URI can), but decoding this to "{" would wreck parsing the template into expressions. "{" is not in the reserved set. Similarly, decoding a pct-encoded "}" or "|" is a problem.

Good catch.


> I think we need to do all the parsing first (into <literal>, <operator>, <varname>, <modifier>, <default>), then decode any pct-encoding in <varname> (regardless of whether the char is in the reserved set). The other fields don't need decoding, except perhaps <default>. Decoding <default> should only be required to support commas in default values. My preferred solution is to have 1 default per <expression> (not 1 per <varspec>), in which case decoding is unnecessary for this field.
> 
> 
> 4. (typo)
> Section 2.4.1 "Prefix Values": change <offset> to <max-length>.

Yep, leftover from name change.

> 5.
> Why can <default> values include "=", but no other <reserved> char [section 2.5 "Value Defaults"]?
> Any <reserved> except comma can be allowed without making the syntax ambiguous so we should allow them.

Yep, that was one of the things you mentioned before that I forgot
to fix, though see below ...

> 6.
> There are no examples with defaults for more than 1 variable. For example, add "x{/var|1st,empty|2nd}" to section 2.5 "Value Defaults".
> The very long list of examples in this section is not good sign to me that this feature's design is intuitive.

Right.  The reason is simply that the examples get too long.

Anyway, I was thinking about defaults this morning and realized that
I don't have any use case for them.  That is, if we assume that the
server is telling the client what values are to okay to place in the
variables, then why would the server ever tell the client that the
variable is undefined?

The only use case that I know of is that it allows the server to
state what parts of the URI space are never empty.  However, I can't
think of anyone who needs that.  Are there other use cases?

It would simplify the examples and algorithm descriptions a lot
if we removed defaults.

> 7.
> Section 3 "Expansion" says that if an error occurs with an expression, then "the expression SHOULD be copied to the result unexpanded". Should the expression at least be pct-encoded (eg the "{" becomes "%7B")? Should <reserved> chars in the expression be pct-encoded?

My goal was to provide the result for error diagnostics, not as
a valid URI.  I should have actually said that in the text.

....Roy

Received on Thursday, 14 July 2011 22:08:58 UTC