Re: URI and IRI Templating (What did I get myself into?)

On 2006/12/27, at 3:26 AM, Joe Gregorio wrote:

> On 12/26/06, Mark Nottingham <mnot@mnot.net> wrote:
>> Note the "or may not." The problem here is that there are many places
>> that information about whether to encode can come from, and it's very
>> difficult to come up with a generic rule that does the right thing
>> *and* doesn't effectively profile URIs by taking options away.
>
> One of the very first things I wrote in my analysis was:
>
>   "First let's dispel the notion that you can come up with
>   the perfect URI-Template to URI translation mechanism
>   that will always produce a valid URI regardless of the scheme. "

I don't want perfect; I'd settle for "not horribly broken."

> On the other hand, allowing the template designer a choice in how  
> the value
> is encoded seems like an interesting idea. I worry, as usual, that
> the results will be way too complex to be adopted, but let's turn it
> into a concrete proposal and see how far it goes.

Your proposal puts the encoding information into the variable name.  
That's one option, but I'm reluctant to encourage putting this kind  
of thing in there, as it encourages URI Templates to become URI  
Schemas, and they'll quickly become unreadable. Encoding is by no  
means the last thing we'll want to associate with a particular variable.

In the past, I've proposed putting the information into the  
documentation of a particular template type, rather than in the  
template itself.

I *think* the trade-off here is that putting it in-template allows a  
really generic template processor to be designed, without any  
knowledge of the particular template in use; the template is  
effectively self-contained. The alternative (i.e., what I'm pushing)  
is that a template processor either has to a) be configured by the  
user to correctly encode different parts of the template, or b) has  
to have template-specific knowledge somehow (internal database?), to  
avoid overloading the templates with metadata.

In any of these approaches, we can try to make the common case easy.  
You say "restricting ourselves to URIs of a particular scheme." I'd  
prefer to think of this as making the schemes we care about (like you  
say, HTTP and mailto are the obvious starting places) do the right  
thing by default, while not preventing the template designer from  
adding more information that augments or overrides the default if  
they wish.

So, a proposal for moving forward: define default per-component  
encoding rules for HTTP and mailto URIs. Allow them to be overridden  
by the template author on a per-variable basis. The open question is  
how; my longstanding preference is out-of-band to the template  
processor. We'd then need to define a standard but extensible  
vocabulary of encoding rules.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 26 December 2006 21:59:58 UTC