W3C home > Mailing lists > Public > uri@w3.org > November 2009

URI template: %-escaping and ASCII templates

From: James Manger <James@Manger.com.au>
Date: Wed, 4 Nov 2009 00:46:29 +1100
Message-Id: <787E00C8-BE91-4469-904C-1A4D1A762C2E@Manger.com.au>
To: uri@w3.org
[Comments on the current URI Template working draft.]


1. It would be helpful if URI Templates (like URIs) can be written in  
ASCII so they can be used in similar places to URIs (eg a Link- 
Template: <template>... HTTP header, similar to the Link: <uri>...  
HTTP header).
2. Templates should support (almost) all of unicode for variable names.

The current draft offers #2, but not #1. I think we can have both.

The current draft is really an "IRI Template" as 'literals' in a  
template can use almost any Unicode characters and 'pct-encoded'  
sequences. Variable names can use almost any Unicode characters -- but  
NOT 'pct-encoded' sequences.

Consequently, while an IRI can be converted to an ASCII URI (and still  
be a valid IRI), a template cannot be converted to an ASCII form.

I suggest allowing 'pct-encoded' sequences in 'varname'. These would  
be decoded before using the resultant variable name to lookup the  
variable value.
The 'vartype' used to indicate when the variable is an associative  
array would have to be changed from '%' to another special character.

The definitions become:
   varspec  = [ vartype ] varname [ modifier ] [ "=" default ]
   vartype  = "@" / something other than "%"
   varname = 1*( varchar / pct-encoded )
   varchar = ALPHA / DIGIT / "." / "_" / ucschar / iprivate

Then if you need to put a URI Template into an ASCII protocol, you can  
%-escape any non-ASCII chars in literals and variable names -- it will  
still be a valid URI Template.


P.S. I would avoid using '%' for anything other than %-escapes to  
minimise potential human confusion -- even if it is technically  
unambiguous.


James Manger
Received on Tuesday, 3 November 2009 13:47:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC