Subject: PaceLinkDelicious, PaceLinkConstruct: @rel values

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 10:39:11 -0700

Okay, I'll argue this now: I for one would like to keep more @rel 
values than PaceFieldingLinks retains.  From PaceLinkDelicious and 
PaceLinkConstruct:

about: The URI in the href attribute points to a resource that is the 
topic of an entry. (sort of like "the primary 'related' link")

start, next, prev: moving the "sliding window" along the 
feed--necessary if one wants to "catch up" on missed entries.

comment: I assume primarily to point to a comments feed for the entry

There are others to which I wouldn't object, but which I myself would 
find less useful, so won't mention here.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Nov 2004 12:53:30 -0500

Antone Roundy wrote:
> 
> Okay, I'll argue this now: I for one would like to keep more @rel values 
> than PaceFieldingLinks retains.  

The point of PaceFieldingLinks is that you can register whatever you want.

Antone Roundy wrote:

 > unless Link Constructs are constrained to
 > the point where an application can handle unknown Link Constructs in
 > some default way without...how to say it...doing something stupid, it
 > doesn't matter whether the application can recognize unknown Link
 > Constructs or not.

Here's a first try:

3.5
A Link construct is an empty element that describes a connection from an 
Atom document to another Web resource. When a link is activated, User 
Agents are expected to visit the linked resource, rather than apply 
metadata such as schema or styling information as is common in HTML 
dialects.

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Mon, 15 Nov 2004 10:25:35 -0800

--On Monday, November 15, 2004 12:53:30 PM -0500 Robert Sayre <[email-masked]> wrote:
> Atom document to another Web resource. When a link is activated, User Agents
> are expected to visit the linked resource, rather than apply metadata such as
> schema or styling information as is common in HTML dialects.

As a spider maintainer, I like the "visit" language. Spiders need to
guess whether to visit a link or not. This approach makes things easier
for spiders, and makes Atom more search-friendly.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 11:19:18 -0700

On Monday, November 15, 2004, at 10:53  AM, Robert Sayre wrote:
>> values than PaceFieldingLinks retains.
>
Yes, but if we think it probable that people are going to want links 
for certain purposes (like those I named), leaving them out of the 
initial registry leads to the risk of ending up with:

<link rel="http://vendor-a.com/atom/link/about" ... />
and
<link rel="http://vendor-b.com/atom/link/about" ... />
and
<link rel="http://vendor-c.com/atom/link/about" ... />
and
<link rel="http://vendor-d.com/atom/link/about" ... />

from various different people who all get the same bright idea.  Sure, 
once someone bothers to register "about", we'll slowly converge on 
using the registered value, but I fear that the URI-using values are 
going to linger and duplicate each other for some time.  The risk is 
the opposite of naming collision--multiple names for the same thing.

So, how shall we evaluate which values to have in the initial registry? 
  Here are some questions we might ask about them:

1) How likely is it that the value will be invented & deployed if not 
initially in the spec?
2) How likely is it that multiple values with the same meaning will be 
deployed?
3) How much more difficult will implementing Atom be if the value is 
added to the initial registry?
Any others?

> A Link construct is an empty element that describes a connection from 
> an Atom document to another Web resource. When a link is activated, 
> User Agents are expected to visit the linked resource, rather than 
> apply metadata such as schema or styling information as is common in 
> HTML dialects.
I wouldn't object to that.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Nov 2004 13:42:02 -0500

Antone Roundy wrote:

> The risk is the opposite 
> of naming collision--multiple names for the same thing.

This is a problem for any format that's extensible in a decentralized 
manner. There's nothing we can do about it.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 12:09:01 -0700

On Monday, November 15, 2004, at 11:42  AM, Robert Sayre wrote:
> Antone Roundy wrote:
>> The risk is the opposite of naming collision--multiple names for the 
>> same thing.
>
There is something we can do about it--we can build a few more values 
into the initial registry which are likely to get created (though 
perhaps as URIs rather than, or in addition to, in the 
registry--leading to duplication).  Sure, we won't forestall all 
duplication, but why not try to exercise a little judgment and deliver 
an initial spec with things that are likely to come up already built in?

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Nov 2004 14:51:49 -0500

Antone Roundy wrote:
> perhaps as URIs rather than, or in addition to, in the registry--leading 
> to duplication).  Sure, we won't forestall all duplication, but why not 
> try to exercise a little judgment and deliver an initial spec with 
> things that are likely to come up already built in?
> 

The draft doesn't list a lot of rel values because we couldn't come to 
consensus on them. There's no reason to get bogged down in this 
discussion. There's a registry. People will use it.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 13:19:20 -0700

On Monday, November 15, 2004, at 12:51  PM, Robert Sayre wrote:
> consensus on them.
The API draft has a number of rel values which PaceFieldingLinks is 
trying to remove.

> There's no reason to get bogged down in this discussion.
My recollection is that where we've bogged down is on discussion of 
whether and how to make link extensible, and that discussion of 
specific @rel values has simply been drowned out by that discussion.  
But if no one speaks up in support of "about", "start", "prev", "next" 
and "comment", then fine--I'll shut my mouth.

> There's a registry. People will use it.
There's a way to mint @rel values without the registry.  People will 
use it.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Nov 2004 15:40:32 -0500

> The API draft has a number of rel values which PaceFieldingLinks is 

Those are already gone, per PaceMoveLinkElement. Also, I just noticed 
PaceLinkAttrDefaults is incorrectly listed for closure. It was accepted 
and is included in format-03.[0] Those two Paces took care of those values.

> whether and how to make link extensible, and that discussion of specific 
> @rel values has simply been drowned out by that discussion.  But if no 
> one speaks up in support of "about", "start", "prev", "next" and 
> "comment", then fine--I'll shut my mouth.
> 

The way to do this is to write a proposal. This argument is unrelated to 
PaceFieldingLinks, isn't it?

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg10651.html

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 15 Nov 2004 21:54:16 +0100

On Mon, 15 Nov 2004 12:09:01 -0700, Antone Roundy <[email-masked]>  
wrote:

> into the initial registry which are likely to get created

I agree with Antone. The link relations he enumerated are well-proved in  
the HTML world and I see absolutely no reason for them not to be used in  
Atom as well. And if we get to the very unlikely spot that they aren't  
used at all -- is that really so awful?

+1 to Antone's suggestion, iow.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 13:56:00 -0700

On Monday, November 15, 2004, at 01:40  PM, Robert Sayre wrote:
>>> The draft doesn't list a lot of rel values because we couldn't come 
>>> to consensus on them.
> Those are already gone, per PaceMoveLinkElement.
Scheduled to be gone from the API spec, yes, but considering that Pace 
alone, moved into the format spec.

> Also, I just noticed PaceLinkAttrDefaults is incorrectly listed for 
> closure. It was accepted and is included in format-03.[0]
>
Ay carumba!  Tim did in fact make that call, and nobody objected.  
Okay.  For my part, I'm on the "we shoulda kept 'em in" side of the 
lack of consensus, but if nobody else cares, I'm not going to continue 
to fight for the cause.  I would have appreciated seeing specific 
arguments against each...which I don't THINK I ever saw.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 16 Nov 2004 08:45:30 +0900

>The point of PaceFieldingLinks is that you can register whatever you want.

I have to admit that I'm not an expert on @rel values.

But I think that PaceFieldingLinks is essentially orthogonal to the number
of link types predefined in the spec. That could be close to 0, or it could
be a rather long list.

I personally think that most if not all link types currently used
in the wild shoud be predefined; there is no point in forcing a wave
of registrations to IANA for things that we anyway know will be used.

This is similar to how the 'charset' registry was started. For the
language tag registry, the base was a pre-existing standard. Having
some good examples in the registry from the start will also help
future registrants.

Regards,    Martin.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 16 Nov 2004 11:11:35 +1100

On 16/11/04 10:45 AM, "Martin Duerst" <[email-masked]> wrote:

> I personally think that most if not all link types currently used in the wild
> shoud be predefined; there is no point in forcing a wave of registrations to
> IANA for things that we anyway know will be used.
> 

+1

> Having some good examples in the registry from the start will also help future
> registrants.
> 

+1

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Nov 2004 20:36:07 -0500

> of registrations to IANA for things that we anyway know will be used.

I would be OK with this, but I don't want to give the impression that 
applications have to support our initial list of rel values. For 
example, I can see many applications not caring about rel="comments".

Does the spec have to list the initial values of the registry, or can we 
work that out separately?

Robert Sayre

P.S. -- http://groups.yahoo.com/group/NetNewsWire/message/1757

---

From: Eric Scheid <[email-masked]>
Date: Tue, 16 Nov 2004 12:59:34 +1100

On 16/11/04 12:36 PM, "Robert Sayre" <[email-masked]> wrote:

> applications have to support our initial list of rel values.

the proposed spec text already says this:

    The value of rel describes the meaning of the link, but does
    not impose any behavioral requirements on implementations.

e.

---

From: Robert Sayre <[email-masked]>
Date: Mon, 15 Nov 2004 21:23:03 -0500

>     not impose any behavioral requirements on implementations.

Yes, I've read the Pace. That doesn't mean that the initial values won't 
be considered "special" by implementors.

In any case, this debate is orthogonal to any Pace being considered 
right now. You guys are debating things that have already been accepted.

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 16 Nov 2004 03:35:12 +0100

On Tue, 16 Nov 2004 08:45:30 +0900, Martin Duerst <[email-masked]> wrote:

> But I think that PaceFieldingLinks is essentially orthogonal to the  
> number of link types predefined in the spec. That could be close to
> 0, or it could be a rather long list.

I agree with you in that.

> of registrations to IANA for things that we anyway know will be used.

+1. We already know a lot about current practice, in HTML, RSS and even  
Atom. We also know something about needs that aren't fulfilled by any  
standards. We should at least cater for current practice and bake those  
@rel values into the spec.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 15 Nov 2004 21:32:16 -0500

Eric Scheid wrote:
>> in the wild shoud be predefined; there is no point in forcing a
>> wave of registrations to IANA for things that we anyway know will
>> be used.
> +1
	+1. I also support pre-registration of as many of these link types
as we can reasonably think of. It costs virtually nothing to pre-register
this stuff yet it costs a great deal (time, effort, attention) to get things
registered in the future.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 15 Nov 2004 21:36:54 -0500

Robert Sayre wrote:
> Does the spec have to list the initial values of the registry, 
> or can we work that out separately?
	Why create two documents when you can accomplish the job with one?
Often, IETF RFC's that are spread over multiple documents end up suffering
when one document is considered the "essential" stuff and people simply fail
to ever getting around to reading the other stuff... Putting the list of
initial registrations in the spec would do much to get that list more widely
known -- and thus increase interop between systems in the future.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Mon, 15 Nov 2004 19:21:59 -0800

> into the initial registry which are likely to get created

Agreed.  Propose a few and see if you can get consensus.  Write a Pace 
that assumes FieldingLinks.  You might want to wait to see if 
FieldingLinks gets accepted. -Tim

---

From: Tim Bray <[email-masked]>
Date: Mon, 15 Nov 2004 19:29:36 -0800

On Nov 15, 2004, at 5:36 PM, Robert Sayre wrote:

> Does the spec have to list the initial values of the registry, or can 
> we work that out separately?

The current draft of PaceFieldingLinks specifies initial values.  I see 
no problem in having the spec specify as many as the WG can come to 
consensus on. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 20:43:19 -0700

On Monday, November 15, 2004, at 08:21  PM, Tim Bray wrote:
>>>> The risk is the opposite of naming collision--multiple names for 
>>>> the same thing.
>>>
>>> This is a problem for any format that's extensible in a 
>>> decentralized manner. There's nothing we can do about it.
>>>
Will do.  At this point, I think we'll have more fruitful discussion if 
we first nail down the shape of the link element, and then work on the 
list of values.

BTW, in case I hadn't said so, +1 on PaceFieldingLinks and in favor of 
closing any competing Paces assuming text gets added saying that URIs 
in @rel are to be compared character-by-character, case sensitively.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 20:57:22 -0700

> apply metadata such as schema or styling information as is common in 
Two possible changes--both minor nit-picks:

1) Change "Atom document" to "Atom feed or entry"?

2) Change "Web resource" to "internet resource"?

It may be possible to make the language prettier in some way, but 
honestly, I think it's entirely sufficient as it stands.  Do you want 
to make a Pace of it, or shall I?

---

From: Eric Scheid <[email-masked]>
Date: Tue, 16 Nov 2004 15:55:46 +1100

> 1) Change "Atom document" to "Atom feed or entry"?

eithr way, does this mean we can't use <link> in <author> or other <head>
elements?

e.