- From: Manger, James H <James.H.Manger@team.telstra.com>
- Date: Thu, 14 Jul 2011 02:19:46 +1000
- To: URI <uri@w3.org>
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. 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. 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>. 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. 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. 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? -- James Manger
Received on Wednesday, 13 July 2011 16:20:31 UTC