Subject: Re: PaceLinkRelMechanism

From: Eric Scheid <[email-masked]>
Date: Sun, 10 Oct 2004 00:16:39 +1000

On 9/10/04 8:24 PM, "Danny Ayers" <[email-masked]> wrote:

> On Sat, 09 Oct 2004 12:23:31 +1000, Eric Scheid <[email-masked]>
> wrote:
> 
>> On 9/10/04 4:05 AM, "Danny Ayers" <[email-masked]> wrote:
>> 
>>> If there is no clear consensus on this I would suggest it be revisited with
>>> the extensible form of the rel attribute reduced to a simple URI.
>>> 
>> -1 to this pace, and -1 to struggling to find consensus ... I'm not so sure
>> we really need to try so hard to solve this problem so soon. The theoretical
>> dangers of @rel collisions are pretty slight.
>> 
> I don't understand - are you suggesting that @rel should be arbitrary strings?
> 
I'm saying the likelihood of an actual collision is so low because we still
have a relatively small community. Given the low risk, it's not something
which should hold back the idea of an extensible list of @rel values (vs.
limiting ourselves to an enumerated list).

>> oh yeah, -1 on using URIs instead of tokens in @rel. It makes the feed even
>> bulkier,
>> 
> I don't think half-a-dozen or so extra chars in a link are a big deal,
> especially compared with the restriction of having an ennumerated set of
> tokens and/or creating a new token mechanism.
> 
"http://" is seven characters, plus a domain name, plus another slash, plus
whatever comes next, plus what would normally be the @rel value (eg.
"next"). That's a lot of extra characters. I hope your not suggesting
relative URIs, especially since we'd want to see the same tokens used by
multiple publishers (plus the problem of canonicalising relative URIs for
comparison purposes).

>> prevents considering the idea of space delimited tokens (+/-),
>> 
> I mut have missed that bit - I'm assuming you mean having multiple tokens in a
> rel? What's wrong with using spaces?
> 
well, doesn't completely prevent them. certainly makes it messy to think
about it though ... there's only one other instance of an element which can
have space delimited URIs versus an uncounted number which have just the one
URI value.

> (Are multiple tokens going to be common enough to justify this option rather
> than simply having multiple link elements?)
> 
maybe, maybe not, that's why I wrote (+/-). I like the idea of being able to
inject qualifiers. eg. @rel="via trusted xfn.employer" or @rel="next
precache"

>> and raises the horrible question of canonicalisation all over again.
>> 
> Not necessarily - it would make sense to use the existing definitions.
> 

existing definitions of canonicalisation?

e.