Subject: Options for link extensibility

From: Tim Bray <[email-masked]>
Date: Mon, 18 Oct 2004 13:33:48 -0700

Our discussion has turned up four basic strategies for link 
extensibility.  I think that before we argue any more about atom:link 
syntax, we need to have consensus at the meta level, or prove that 
we're not going to get consensus.

How to do link extensibility:

LE0 Don't:  Atom has no abstract notion of a link.

LE1 Hardwired:  Itemize the different kinds of links in the Atom 
specification.  Extensibility requires a new version of the Atom 
specification.

LE2 Registry:  The types of links are in a (presumably IANA) registry, 
which can be extended using a well-understood process.

LE3 URIs:  Non-centralized extensibility is achieved by using URIs to 
name types of links.

Note that these do not involve syntax arguments.  If we manage to 
converge on one of these, then we argue about the syntax (e.g. for LE4, 
qnames or full URIs), but that's a much more focused discussion than 
we've managed to have so far.

If people think it's a good idea, we could run a -1/0/+1 survey on the 
wiki (I'd be "0" on all four). If people want to speak up and argue 
that one of these options is substantially better than all the others, 
that would be appropriate: please include LE0, LE1, LE2, or LE3 in your 
subject line.  If such an argument gets a lot of support and little 
opposition, we can discard a bunch of the Paces and move to focus on 
the syntax.

My sense of the group is that LE2 is perhaps slightly more likely than 
any other alternative to gain consensus, but I could very easily be 
wrong.

   -Tim

---

From: Robert Sayre <[email-masked]>
Date: Mon, 18 Oct 2004 16:41:41 -0400

> any other alternative to gain consensus, but I could very easily be wrong.

Could Paul or anyone else versed in IANA registration of such things 
outline the general procedure for doing so? What does an author have to 
do before unleashing a new link type on the wild? Is it realistic to 
expect that they will actually do it?

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Mon, 18 Oct 2004 15:01:17 -0600

>LE3 URIs:  Non-centralized extensibility is achieved by using URIs to 

Would a union of these two options make sense?  A core set of known and 
well-understood link types managed by IANA with extension types identified 
using URI?

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

Tim Bray <[email-masked]> 
Sent by: [email-masked]
10/18/2004 01:33 PM

To
Atom Syntax <[email-masked]>
cc

Subject
Options for link extensibility

   -Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 18 Oct 2004 14:24:01 -0700

At 4:41 PM -0400 10/18/04, Robert Sayre wrote:
>outline the general procedure for doing so? What does an author have 
>to do before unleashing a new link type on the wild? Is it realistic 
>to expect that they will actually do it?

When an RFC creates an IANA registry, the RFC states how that 
registry will be updated. We can say whatever we want, as long as 
what we say can be understood by a secretarial-type person. 
(Currently, a very nice secretarial-type person, FWIW.)

Common updating choices today are:

- Must have an RFC of any sort

- Must have a standards-track RFC (they're harder to get but they 
also have more review in the IETF)

- Must have the agreement of the IESG (which often means "must have 
the agreement of a couple of members of the IESG who tell the other 
ones 'this is OK'")

- Must have the agreement of an IESG-appointed "expert" (who usually 
has a mailing list to discuss the requests)

- Only needs a message to IANA (this is now rare due to abuse)

We can do whatever we want, but we'll probably have to live with the results.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 19 Oct 2004 09:55:23 -0400

> LE3 URIs:  Non-centralized extensibility is achieved by using URIs to

First, isn't it a bit backward to be talking about link extensibility
before talking about general format extensibility?

Modulo that bit of parlimentary shuffling, I would have to 
settle on LE0. Here is my reasoning:

I believe that we started this group to clean up
and create a solid foundation for syndication technology, a
foundation that we fully expected a raft of innovations to be
built upon. I think there is value in being able to let a 
thousand flowers bloom and letting any person with a web 
site propose extensions[1][2].Given that premise, 
I don't think LE1 or LE2 are appropriate.I believe they
raise the bar too high for innovation. 

LE3 is a good choice if we agree there is a common 
abstract notion of a link, and that it is worth segregating
it out. I will note however that since we can transport HTML as our
content, and said HTML can contain links, and images,
and SVG, and Flash, etc that an abstract link mechanism
is in no way mandatory. I will also note that RSS (in all it's 
varieties) has survived fine w/o such a mechanism.
Ahh, but what about enclosures? They are handled in RSS via
general format extension and not a generic link syntax.

Which, for all these reasons combined, leads me to select LE0.

   Thanks,
   -joe

[1] http://wellformedweb.org/news/wfw_namespace_elements
[2] http://wellformedweb.org/news/35

-- 
Joe Gregorio        http://bitworking.org

---

From: Graham <[email-masked]>
Date: Tue, 19 Oct 2004 14:21:47 +0100

> which can be extended using a well-understood process.

I don't like this at all. No one will use it, and it basically requires 
consensus in the group that the extensibility mechanism in XML is a 
failure, when I think it's actually dead good.

> LE3 URIs:  Non-centralized extensibility is achieved by using URIs to 

+1 if there's a sensible way to do it (Robert's yesterday is the only 
way I've seen)

> that would be appropriate: please include LE0, LE1, LE2, or LE3 in 
> your subject line.  If such an argument gets a lot of support and 
> little opposition, we can discard a bunch of the Paces and move to 
> focus on the syntax.

-1000 to a vote. I don't like the way you've set this up since my 
support/objection depends almost entirely to which syntax we choose.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 11:14:48 -0400

Joe Gregorio wrote:

> is in no way mandatory.

I'll spring for LE3.

Links in the payload is a non-argument. They might as well not even be 
there, since aggregators are free to strip whatever they see fit, and 
those links might live in HTML tag soup.

I think the notion of Media-Independent links is valuable. The only 
problem with the HTML4 syntax is that it's a little looser than we want 
to be (unqualified, composable rel names).

"A link is a connection from one Web resource to another. Although a 
simple concept, the link has been one of the primary forces driving the 
success of the Web.

The default behavior associated with a link is the retrieval of another 
Web resource."[0]

enclosure is a good example, because retrieval is still useful, even if 
the client doesn't understand the paperclip semantics. It's nothing new, 
just a way to annotate a hyperlink with additional semantics, which 
doesn't require a lot of infrastructure. That we have people writing 
rel="related" is evidence enough that we have a general idea of a link.

Robert Sayre

[0] http://www.w3.org/TR/REC-html40/struct/links.html

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 19 Oct 2004 16:24:10 +0100

> LE0 Don't:  Atom has no abstract notion of a link.

0. If there is an abstraction we haven't found it yet.

> specification.  Extensibility requires a new version of the Atom 

-1. Assumes we have an abstract notion of a link; see above. Also, 
assumes we are closed for extension and modification of link types 
and link operands. I'm rarely that confident about such things. 
Finally, closes the door on innovation and surely encourages daft 
workarounds for what will be obvious requirements two years from now 
- not much fun there.

> which can be extended using a well-understood process.

-1. My crystal ball tells me hardly anyone will use that process - 
it's way too prim and bound to take the fun out of things.

> LE3 URIs:  Non-centralized extensibility is achieved by using URIs to 

+1. There are a number of ways to attach information to a URI. It 
also leaves an option for us or others to revisit this matter.

I agree with Joe's position, but think a) it makes sense to leave a 
hook, b) we can do that without assuming an abstraction. What we'd 
be saying is that we suspect signaling control codes from publisher 
to reader might be an interesting thing to do for link-like things, 
but we don't know what those codes might be at the moment since we 
can't agree on link-likeness - go innovate.

IOW:

1. leave a hook for someone to determine future mechanisms and 
abstractions.

2. Mandate a noop/default URI value now for that hook.

3. Don't engage the WG any further in trying to determine what the 
mechanisms and abstractions could be for the time being.

4. *Strictly timebox* how long we have to determine the form and 
nature of LE3; if we don't ship something for the editors within 
that time, fall back to LE0. [If we don't agree to timebox. my 
consensus immediately goes to LE0.]

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 19 Oct 2004 09:27:17 -0700 (PDT)

> Which, for all these reasons combined, leads me to

+1 

As I mentioned earlier, if the WG can come up with a
well defined notion of what it means to be a link I'd
go for LE3 otherwise I'm in the LE0 court. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 12:37:55 -0400

> go for LE3 otherwise I'm in the LE0 court. 

Kind of a nebulous requirement, don't you think? Could you expand on 
what a "well-defined notion" would be?

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 19 Oct 2004 09:59:13 -0700 (PDT)

> what a "well-defined notion" would be?

In practical terms, I want a description good enough
that I can write one chunk of code for dealing with
<link> elements and it can deal with all the link
elements that may show up either from the Atom WG or
as extensions in a consistent AND useful manner. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 13:21:46 -0400

> as extensions in a consistent AND useful manner. 

OK. Let's examine the current practice. Here's what Mozilla does with 
unknown link elements:

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/linkToolbarHandler.js#165

It ignores any link that contains a @rel value that includes:

* stylesheet
* icon
* fontdef
* p3pv
* schema

So, roughly, the resource pointed to by the link should be a standalone 
resource that could replace the entry in a viewport, not information or 
metadata related to policy or display of the entry.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Tue, 19 Oct 2004 21:02:58 +0200

+1

> before talking about general format extensibility?

Yes. 

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 19 Oct 2004 23:30:28 +0200

> LE3 URIs:  Non-centralized extensibility is achieved by using URIs to  

I'm +1 on this, but would like it to be either recommended or required  
that the URI's are dereferencable so that the meaning of it can be  
explained to the human implementing support for a given URI.

Namespaces almost always deploy this practice today, but it isn't very  
clear what you are to expect at the end of a namespace HTTP URI. I'd like  
that to be clear, or would at least like there to be provided some  
guidelines, in this case.

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 20 Oct 2004 00:07:55 +0200

>LE3 URIs:  Non-centralized extensibility is achieved by using URIs to 

I do not really understand these alternatives, is this about whether and
how to allow people to put custom values into the rel attribute? Or is
it about <link rel="foo" /> vs <foo />? In particular the difference
between LE0 and LE1 is not clear to me.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 00:43:14 +0200

> metadata related to policy or display of the entry.

Which seems reasonable for a tool built around one big
document-oriented viewport. One of the notable features of Atom (and
RSS) is the way metadata is pushed into greater significance. Rather
different.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 18:48:28 -0400

> RSS) is the way metadata is pushed into greater significance. Rather

So... what's your objection? Nothing is stopping you from creating some 
other element that has a URI in it.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 13:30:05 +0200

> other element that has a URI in it.

Sure, and hopefully I'll have time to be Pace-oriented later in the
day. I'm just suggesting that the way Mozilla uses HTML's <link> may
not be a good basis for Atom's <link>, for two main reasons -

1. the link element in HTML in use has more than one nature, in
particular, aside from viewport material it has:

* stylesheet
* icon
* fontdef
* p3pv
* schema

(all ignored by Moz)

2. that Atom applications differ from HTML applications in a way that
cuts right through <link> - the content/metadata balance

Cheers,
Danny.

-- 

http://dannyayers.com