On Monday, November 15, 2004, at 10:53 AM, Robert Sayre wrote:
Antone Roundy wrote: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: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.
<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?
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.
I wouldn't object to that.
