RE: URI Template experience

Eran,

I think {var} and {var!} would be a better URI template syntax to indicate when %-escaping is or isn't required for reserved characters.

draft-hammer-discovery uses {%var}. Using '%' as the special indicator (as opposed to '!') is perhaps more suggestive of what it means. However, variable names can then not include any %-escaping themselves. For instance, it only works if variable names never need escaping, or a separate escaping mechanism just for variables names is added (yuck).
<http://tools.ietf.org/rfcmarkup?doc=draft-hammer-discovery#section-6>

I think it would be easier to understand and less error-prone to implement if '%' only ever appears in a template (like it only ever appears in a URI or IRI) as part of a %xx escape sequence.


I like '!' as an indicator that a substituted value is allowed to include (unescaped) reserved characters. It suggests caution, warning, danger… which seems appropriate when the substituted value can "do anything".



James Manger
James.H.Manger@team.telstra.com
Identity and security team — Chief Technology Office — Telstra


----------
From: uri-request@w3.org [mailto:uri-request@w3.org] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, 20 September 2009 7:49 AM
To: Roy T. Fielding
Cc: Mark Nottingham; Joe Gregorio; URI
Subject: RE: URI Template experience

I am working on two drafts (XRD in OASIS, draft-hammer-discovery in IETF) which make use of URI templates. Assuming this proposal will not be published as an RFC within 6 months, these drafts will need to define their own syntax. The current proposed syntax in XRD is extremely limited, and only includes simple variable substitution (no lists or arrays) and a single operator ('%') to require encoding of reserved characters.

Any reason why the reserved substitution operator is '+' and not '%' (as in percent-encoded)?

I want to explicitly design it to be a compatible subset of the work being proposed here to allow libraries written for this proposal to process the more limited XRD template syntax as well. The only thing I need to accomplish that is to make sure the encoding operator is the same (which right now means changing my proposal to use '+' instead of '%').

Any advice on how to deal with the different timelines for these specs?

EHL

Received on Wednesday, 30 September 2009 02:12:39 UTC