Subject: Re: Comments Draft

From: Antone Roundy <[email-masked]>
Date: Mon, 1 Aug 2005 10:20:05 -0600

On Sunday, July 31, 2005, at 10:24  AM, A. Pagaltzis wrote:
> * Antone Roundy <[email-masked]> [2005-07-31 01:15]:
>> I could add more, but instead, here's my suggestion for
>> replacing that sentence:
>>
>>     If the resource being replied to is an atom:entry, the
>>     value of the href attribute MUST be the atom:id of the
>>     atom:entry. If the value of the type attribute is
>>     "application/atom+xml" then the href attribute MUST be the
>>     (URL/URI/IRI) of an Atom Entry Document containing the
>>     atom:entry being replied to.
>
> This undermines the purpose of the link.

I'd say that not being able to tell whether @href in 
link[@rel="in-reply-to"] is dereferencable or not is what undermines 
link.

The primary purpose of link[@rel="in-reply-to"] is to identify the 
resource (which may be an atom:entry) being replied to.  If that 
resource is an atom:entry, then the appropriate identifier for it is 
it's atom:id.

If "If the resource being replied to is an atom:entry, the value of the 
href attribute MUST be the atom:id of the atom:entry" doesn't sound 
like a good rule, then I'd argue that using atom:link to identify the 
resource being replied to is a bad idea.

As I've said before, I think that stuffing data that happens to be a 
URI but may not be dereferencable into link/@href is a bad idea.  If we 
ARE going to do it, then I think we need a way to at least hint at 
whether it's a dereferencable link or some other data stuffed into a 
link element.

Here's what the spec says @type is for:

    On the link element, the "type" attribute's value is an advisory
    media type; it is a hint about the type of the representation that is
    expected to be returned when the value of the href attribute is
    dereferenced.

If @href isn't dereferenable, then the existence of @type is deceptive. 
  I suppose it could mean "when I saw it, it was in some kind of Atom 
document", but so what?  What if the feed gets converted to RSS 2.0, 
the atom:id is put into guid, and I find the entry in the RSS feed?

> Atom Entry Documents can move around; their IDs are eternal.
True, so you could just omit @type from this link if you're concerned 
that your entry document might move.  Or we could go with something 
like this:

<ext:in-reply-to id="...">
	<atom:link rel="found-in-entry-document" href="..." />
	<atom:link rel="found-in-feed-document" href="..." />
</ext:in-reply-to>

Or we could just stick with what has been proposed, perhaps including 
what I proposed in my last message, and if they entry document moves, 
then oh well, the web has another broken link just as it would in what 
I proposed just above here or in any case where a dereferencable link 
was published, but the atom:id would still be valid.  If after moving 
the entry document, one were to publish the in-reply-to link again, it 
would be appropriate to remove the @type attribute.

...okay, that last sentence suggests that what I propose just above 
here is a superior way to having possibly-derefencable atom:links, 
because you could update the found-in-entry-document link if it got out 
of sync with the location of the document.  Otherwise, we'll have to be 
limited to linking to the feed in which the entry is found.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 1 Aug 2005 19:27:40 +0200

* Antone Roundy <[email-masked]> [2005-08-01 18:30]:
> link[@rel="in-reply-to"] is dereferencable or not is what
> undermines link.

It undermines the purpose of the link insofar as IMO the entry
being replied to MUST ALWAYS be identified by its atom:id. I am
strongly -1 on letting the producer choose to identify it by its
network location in any way or shape. Such a location is valuable
as additional information to provide, but it’s strictly optional.

> If "If the resource being replied to is an atom:entry, the
> atom:entry" doesn't sound like a good rule, then I'd argue that
> using atom:link to identify the resource being replied to is a
> bad idea.

I have already agreed about the fact that atom:link is not the
right vehicle for carrying the atom:id, so there’s no need for
you to preach to the choir. See my "Thread/comment extension
refactoring" post about my current stance.

As for overloading @rel='in-reply-to' to carry either
dereferencable URIs or atom:ids, that would just needlessly
require conditional checks on the consumer end. And because I’m
strongly -1 on omitting the atom:id but also no longer consider
atom:link to be the right place for it, the idea is triply wrong.

> True, so you could just omit @type from this link if you're
> concerned that your entry document might move.  Or we could go
> with something like this:
> 

That makes the information in the nested atom:link elements
inaccessible to compliant clients without threading support, and
it also requires new relationships to boot. Also, note that
entry-sources vs replied-to-entries is an 1:N relationship, so it
would make sense to group replied-to-entries by entry-source,
rather than vice versa.

So then you have

    <link rel="via" type="application/atom+xml" href="http://example.com/feed/">
        <thr:source-for>urn:foo:1</thr:source-for>
        <thr:source-for>urn:foo:2</thr:source-for>
    </link>

which properly reuses a known relationship, so that even a
non-thread-aware consumer can do something interesting with the
information, even if it does not understand it quite as precisely
as a client with proper thread awareness.

Again, see my "Thread/comment extension refactoring" post about
my current thinking.

> ...okay, that last sentence suggests that what I propose just
> above here is a superior way to having possibly-derefencable
> atom:links, because you could update the
> found-in-entry-document link if it got out of sync with the
> location of the document. Otherwise, we'll have to be limited
> to linking to the feed in which the entry is found.

I don’t see why that is an advantage specific to using the @type
attribute on atom:link in the way you proposed, rather than
a benefit that *any* approach for including a source URL would
provide.

Again, please see my other post. The approach we started with
(relying mostly on @rel='in-reply-to' which I proposed) was
hackish, which was okay as long as it was minimal, but is no
longer tenable now that we are trying to accomplish even a bit
more. My new proposition deals with all of your objections and
several other issues I ran across on my own.

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

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Aug 2005 12:02:57 -0700

I definitely appreciate all of the feedback on this.  The conversation 
has definitely been helpful.  Personally, however, I think that the 
elegance and simplicity of in-reply-to and replies link rel values 
trumps defining them as elements in a separate namespace or an otherwise 
perfectly engineered solution.  As for specifying the source of the 
resource being replied to, a namespace extension inside the link element 
is probably the best way to go.  So what we end up with is:

<feed>
   ...
   <link rel="replies" href="http://www.example.com/myfeed.xml" />
   <entry>
      ...
      <link rel="in-reply-to" href="tag:example.com,2005:1">
         
<thread:source>http://www.example.com/sourcefeed.xml"</thread:source>
      </link>
   </entry>
</feed>

Implementations that are not thread aware can safely drop thread:source 
as they won't be able to do anything useful with the in-reply-to link 
anyway (whether it is dereferenceable or not). 

While this approach may be a bit hackish, I believe that it's natural, 
simple and unambiguous enough to solve the problem effectively.  Using 
the via link just seems unnatural to this purpose in that we're not 
expressing a relationship like "The information contained here-in was 
received through..." we're expressig "The information contained here-in 
is a response to...".  Via works great for the former and doesn't fit 
for the latter.  All of the examples that have been offered built around 
the via mechanism just seem entirely too verbose for comfort... 
especially given that we're trying to optimize for optional metadata 
that hints at a relationship that can't be reliably confirmed (e.g. that 
the entity being replied to MAY exist at the specified source).

Thoughts?

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 Aug 2005 06:46:39 +0200

* James M Snell <[email-masked]> [2005-08-04 21:15]:
> Personally, however, I think that the elegance and simplicity
> of in-reply-to and replies link rel values trumps defining them
> as elements in a separate namespace or an otherwise perfectly
> engineered solution. As for specifying the source of the
> resource being replied to, a namespace extension inside the
> link element is probably the best way to go.

I consider it stupid blunder to have proposed using atom:link for
this, not elegant and simple.

You need a link and an extension element either way.

So choose to squirrel away information that even clients without
threading support could use inside a namespaced element, and
instead put information they have no use for in a place they can
access. What a mess.

Why not do it the other way around?

> Using the via link just seems unnatural to this purpose in that
> we're not expressing a relationship like "The information
> contained here-in was received through..." we're expressig "The
> information contained here-in is a response to...".  Via works
> great for the former and doesn't fit for the latter.

So just drop back to “related.” Either way the exposed
information is sensibly usable even by clients without threading
support; they don’t know *why* it’s related, but it certainly is
useful to let them partake of that information.

> All of the examples that have been offered built around the via
> mechanism just seem entirely too verbose for comfort... 

Verbose, sure. Too verbose, how?

> especially given that we're trying to optimize for optional
> metadata that hints at a relationship that can't be reliably
> confirmed (e.g. that the entity being replied to MAY exist at
> the specified source).

You are going to need a namespace any way you turn it. If you
really don’t care about exposing as much information as they can
use to as many clients as possible, and brevity is such a
concern, then maybe it should be

    <thr:in-reply-to src="http://example.com/atom">urn:foo:1</thr:in-reply-to>

which makes this a Structured instead of a Simple Extension
Element, but then maybe that was unavoidable anyway.

Of course, conscientous producers will drop in a

    <link rel="related" href="http://example.com/atom" />

for good measure, so it’s verbose anyway.

Hmm.

Huh.

Interesting.

I like this even better than my previous proposition.

D’oh. Screw sticking to Simple Extension Elements, this is
better. This is *natural* – no funny business with markup inside
atom:link elements. Each piece of information is available to as
broad an audience as possible: threading-aware clients can
correlate the “related” links to the source attributes, and
non-aware clients can at least tell there is something related at
the indicated resource.

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Aug 2005 22:07:10 -0700

>this, not elegant and simple.
;-) Let's hear what you really think ;-)

>for good measure, so it’s verbose anyway.
ok.. ok.. I can take a hint ;-) ... according to my wife it only takes 
about a couple dozen beatings to get me to think straight and listen so 
I think we're making progress here ...

How does this work for you?

  <thr:in-reply-to id="urn:foo:1" type="application/atom+xml" 
src="http://www.example.com/atom" />

With a definition of:

  inReplyToNonDereferenceable = element thr:in-reply-to {
    attribute id { atomUri },
    attribute type { atomMediaType }?,
    attribute src { atomUri }?
 }

  inReplyToDereferenceable = element thr:in-reply-to {
    attribute href { atomUri },
    attribute type { atomMediaType }?,
 }

This seems to tie in everything we've been discussing to this point.  In 
the NonDereferenceableForm, @id is used to express an opaque 
identifier.  @src MAY be used to specify a dereferenceable location 
where the resource identified by @id might be found.  In the 
Dereferenceable form, @href is used to specify a location.

Used in context, it would look like:

<feed>
  <link rel="replies" href="http://www.example.com/atom" />
  ...
  <entry>
     ...
     <thread:in-reply-to id="tag:example.com,2005:1" 
type="application/atom+xml" src="http://www.example.com/myotheratomfeed" />
     <thread:in-reply-to href="http://www.example.com/entries/1" 
type="application/atom+xml" />
     <link rel="related" href="http://www.example.com/myotheratomfeed" />
     <link rel="related" href="http://www.example.com/entries/1" />
  </entry>
</feed>

Does this work or do I need to be taken out and flogged again?

- James

---

From: Eric Scheid <[email-masked]>
Date: Fri, 05 Aug 2005 15:59:51 +1000

> src="http://www.example.com/atom" />

how about this instead

    <link rel="in-reply-to"
          href="http://www.example.com/atom"
          type="application/atom+xml"
          thread:idref="urn:foo:1" />

this way processors that have a basic understanding of what a <link> is can
still do something useful.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 Aug 2005 09:50:36 +0200

> Does this work or do I need to be taken out and flogged again?

Absolutely that does work for me.

(Sorry for the curt reply – I am off to catch a plane in a few
minutes and won’t have ’net for a week. Tried to get this out
before I am gone. And sorry for the harsh tone. :-) )

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 5 Aug 2005 11:48:17 +0200

* Eric Scheid <[email-masked]> [2005-08-05 08:10]:
> this way processors that have a basic understanding of what a
> <link> is can still do something useful.

No, that requires entries to be located in a feed available at a
dereferencable URI because @href is not optional. So it would
preclude replying to feeds delivered via SMTP, XMPP or other
protocols that don’t work like that. You can try messy
workarounds, but please, let’s not go there yet again. Please
read my “refactoring” post for a long trail of thoughts which
addresses pretty well everything which has been brought up since.

Regards,

---

From: Tim Bray <[email-masked]>
Date: Fri, 05 Aug 2005 04:55:58 -0700

> still do something useful.

Uh, consider

<link rel="ultimate-source-of-all-evil-STAY-AWAY"
       href="http://example.org/evil" />

What useful thing is there that software could sanely do, knowing  
only that something is a link? -Tim

---

From: Eric Scheid <[email-masked]>
Date: Fri, 05 Aug 2005 22:16:15 +1000

> only that something is a link? -Tim

not knowing what that particular @rel actually means, it could still treat
it as @rel="related" because the referenced resource is, uh, related.

so, what could software sanely do with a link[@rel="related"], other than
catch on fire?

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 06 Aug 2005 03:20:45 +1000

On 5/8/05 7:48 PM, "A. Pagaltzis" <[email-masked]> wrote:

> protocols that don¹t work like that.

Ah dammit, you're right. There was blood spilled to allow entries to not be
required to have an alternate too, so we can't even point at that.

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 11 Aug 2005 07:07:24 +0200

* Eric Scheid <[email-masked]> [2005-08-05 19:35]:
> ... and it's too late to write a pace with atom:idref, and
> wording saying an atom:link must have at least either an
> atom:href attribute or an atom:idref attribute. That is, one or
> both but not neither.

I dunno if it’d be such a great idea anyway – it just so happens
that it would work for the threading extension, but I’m not sure
it would be very universally useful. But yeah, it *would* work
for this case…

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Aug 2005 22:07:38 -0700

>it would be very universally useful. But yeah, it *would* work
Yes it does work in the comments draft ;-) If you haven't done so 
already, take a look at the version I submitted as an I-D [1].  It uses 
@idref for the ID reference.

- James

[1] 
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-00.txt

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 11 Aug 2005 07:22:12 +0200

* James M Snell <[email-masked]> [2005-08-11 07:20]:
> Yes it does work in the comments draft ;-) If you haven't done
> so already, take a look at the version I submitted as an I-D
> [1]. It uses @idref for the ID reference.

Yeah, but that’s @thr:idref, not @atom:idref. ;-)

Regards,