Subject: RFC 4685 & linking to an atom entry using (ref,source)

From: "Brian Smith" <[email-masked]>
Date: Fri, 14 Sep 2007 23:46:15 +0700

RFC 4685 (the threading extension) defines a new way to link to an atom entry:

    <thr:in-reply-to ref='tag:example.org,2006:/entry-atom-id'/>

This is a link to the atom entry with the given atom ID. Notice that there is no information given about how to retrieve the entry. If you want to add that information, we can add a link to the feed:

    <thr:in-reply-to ref='tag:example.org,2006:/entry-atom-id'
                     source='http://example.org/feed' />

It seems wrong to me to standardize on a mechanism that isn't using URIs for identifying entries, especially since the idea of permalinks already exists for HTML representations of entries. Is this (atom:id,feed-uri) mechanism going to be the standard mechanism to link to individual atom entries in Atom IETF specifications? 

If so, then this mechanism should be generalized. For example, I would like to use it for a "via" link relation and the "related" link relation. For example, it could be implemented as an "entry-link" element that is just like atom:link, except that it has @ref and @source. Then "in-reply-to" would just be a link relation, and I could write:

   <link rel='in-reply-to' href='http://example.org/entry.html'/>

for replying to a web page.

I could then reuse the "in-reply-to" link relation in my entries' HTML representation <html:link rel='in-reply-to'/>

- Brian

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 16 Sep 2007 07:49:44 +0200

* Brian Smith <[email-masked]> [2007-09-14 19:05]:
> It seems wrong to me to standardize on a mechanism that isn't
> using URIs for identifying entries

The Atom ID *is* a URI.

> especially since the idea of permalinks already exists for HTML
> representations of entries.

Atom Entries need not have a permalink. But they must always have
an ID. Permalinks shouldn’t change but sometimes do; Atom IDs
MUST be unchanging.

We started with the exact same mechanism you suggest:
@rel='in-reply-to' links.

It didn’t work.

We originally said the @href is the Atom ID, but such links are
useless to Atom consumers that don’t know `in-reply-to`, just
like thr:in-reply-to elements are useless to Atom consumers that
don’t know what they mean. So there is no gain from reusing
atom:link with overloaded @href.

Also, sometimes you have both a permalink and an Atom ID. It
would be good to provide both. With a single attribute this is
not possible, so you need two.

The logical thing to do is put the permalink in @href and the
Atom ID in an extension attribute. Then such a link is somewhat
useful even to clients that don’t specifically understand
`in-reply-to`.

Except that doesn’t work. There are two problems:

1. The Atom ID would go in an extension element. But what happens
   when you have no permalink? After all, atom:link REQUIRES an
   @href attribute, and with good reason.

2. You have introduced a bad co-constraint. The link extension
   attribute is only valid on links where @rel has a particular
   value.

You really can’t use atom:link for this.

We tried.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 17 Sep 2007 03:46:00 +0700

> @rel='in-reply-to' links.

First, thanks for taking the to reply.

I think you might have skipped over or misunderstood my actual suggestion:

     If so, then this mechanism should be generalized.
     For example, I would like to  use it for a "via" link
     relation and the "related" link relation. For example,
     it could be implemented as an "entry-link" element that
     is just like atom:link, except that it has @ref and
     @source. 

In particular, note that I wasn't suggesting to use <atom:link> for this, but rather a new element <entry-link>.

Let me ask my question a different way. If I want to say that an entry is "related" to another entry, how can I do that? Currently, it is not possible. So, should I use some kind of extension element like this?:
 
    <related ref='atom-id' source='uri-of-feed' xmlns='something-i-make-up'/>

It seems wrong to me to have to define extension elements for every kind inter-entry relationship, when the single atom:link element can handle everything except inter-entry relationships using only one element. That is why I suggested a more general mechanism would be better:
  
    <entry-link rel='related'     ref='atom-id' source='uri-of-feed'/>
    <entry-link rel='in-reply-to' ref='atom-id' source='uri-of-feed'/>
    <entry-link rel='via'         ref='atom-id' source='uri-of-feed'/>
    <entry-link rel='replies'     ref='atom-id' source='uri-of-feed'/>

Basically, it would be exactly like the thr:in-reply-to element, except that it would be able to handle other relationships between entries via the @rel attribute.

Cheers,
Brian

---

From: James M Snell <[email-masked]>
Date: Sun, 16 Sep 2007 15:44:19 -0700

It would likely be better just to write a spec that adds a ref attribute
to the existing atom:like element.  The new attribute would be
considered foreign markup and ignored by existing clients.  It would
look something like:

  <link rel="related" href="..." ref="..." />

The new attribute could be defined within the existing Atom namespace or
defined in a new namespace, it really doesn't matter which.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 17 Sep 2007 13:28:10 +0200

* Brian Smith <[email-masked]> [2007-09-16 23:00]:
> In particular, note that I wasn't suggesting to use <atom:link>
> for this, but rather a new element <entry-link>.

Ah.

But then you have a problem – how do you correlate links and
entry-links?

    <link rel="related" href="http://example.org/2007/foo" />
    <entry-link rel="related" ref="tag:example.org,2007:foo" />

If these are the same piece of information, how can I know? Your
proposed `entry-link` would really need to allow for an `href`
attribute to handle this case.

Considering how little use is being made of the versatility of
atom:link, though, I doubt that any implementors will care about
esoterica like `via` links specified by Atom ID. In this respect
I think defining a new one-off element in a single-use-case spec
like RFC 4685 was the better choice, as it’s easier to relate to
people why they’d want to make the effort to support it.

* James M Snell <[email-masked]> [2007-09-17 01:00]:
> It would likely be better just to write a spec that adds a ref
> attribute to the existing atom:like element. The new attribute
> would be considered foreign markup and ignored by existing
> clients. It would look something like:
> 

That won’t work.

There will be cases where you have an ID but no permalink and
therefore nothing to put in `href`, but `href` is REQUIRED so you
cannot omit it in valid Atom. And to switch that MUST to MAY
you’d have to bump the namespace.

Regards,