Subject: Unofficial Last Call - draft-snell-atompub-feed-thread-04.txt

From: James M Snell <[email-masked]>
Date: Fri, 21 Oct 2005 10:06:45 -0700

All,

At some point over the next couple of days, a slightly modified version 
of the comments extension draft [1] will be published.  The moment it 
publishes will kick off a two week Unofficial Last Call period for the 
spec.  The spec has been stable of the past two months with no major 
issues raised.  Please review the draft.  After two weeks I will review 
any received feedback and, if appropriate, cut a new draft which will 
become the stable version.  After the Atom Protocol work completes, I 
will submit the stable version of the draft as a standards track RFC.

- James

[1] draft-snell-atompub-feed-thread-03.txt (current version)
[2] draft-snell-atompub-feed-thread-04.txt (new version waiting to 
publish... no significant changes)

---

From: "James Holderness" <[email-masked]>
Date: Sat, 22 Oct 2005 14:47:32 +0100

> publish... no significant changes)

Do you have a link for these? The only copy I could find on ietf.org 
was -01.

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Oct 2005 07:44:39 -0700

Ah crap, that's what I get for editing multiple docs at once.  It's 
supposed to be -01 and -02.  I'll get that fixed.  The -01 is the 
current version; the new version waiting to publish has no significant 
updates (just some minor typo stuff) so you should safely be able to 
base your feedback on the -01 version.

---

From: "James Holderness" <[email-masked]>
Date: Thu, 27 Oct 2005 15:34:02 +0100

Sorry for the delay in commenting, but I only got around to looking at this 
in detail today.

Other than a few areas that I think need clarification in the wording, my 
main problem with this proposal is the dereferenceable in-reply-to. While I 
can see why a feed producer may want to include it, I don't see how an Atom 
processor can do anything useful with it (which couldn't be done just as 
easily with existing elements). And if it's not of any use, it seems to be 
that it's just taking up space and complicating the spec.

The easiest way to explain my position is with some use cases. Let's say you 
wanted to reply to a particular item in another Atom feed:

<thr:in-reply-to
  type="application/atom+xml"
  idref="tag:someatomid"
  source="http://www.example.org/someatomfeed"/>

From that alone I can do all sorts of fancy threading in my client (assuming 
the user is subscribed to the source feed) and/or provide a 
button/link/whatever allowing the user to subscribe to the source feed (if 
he isn't already).

If the item being replied to is in the same feed as the reply then the idea 
is pretty much the same except no source attribute is required. That's all 
good.

Now let's say I wanted to reply to a particular item in an RSS feed. Here's 
what I'd expect:

<link
  rel="related"
  type="text/html"
  href="http://www.example.org/rsspermalink.html"/>

You could use an in-reply-to tag, but it's not going to be any more useful 
to me than that (in some cases, less useful). Even with an idref of some 
sort, I still can't thread such a reply. The original article can't link to 
my reply as part of its own threading system and nobody reading the original 
thread can reply to my reply and still have it be part of the original 
thread.

The bottom line is that it's really not part of a thread - it's a completely 
separate message that is merely related to the original. In fact, if you 
were to represent that link as a <thr:in-reply-to> element, the best I could 
do as a client is convert it into a "related" link or a "via" link.

Basically what it comes down to is this. I think <thr:in-reply-to> should be 
reserved for threading of atom entries only. Any other replies should be 
referenced with a "related" or "via" link element. There's no need for a 
type since it should always be "application/atom+xml". The source should 
always point to an Atom feed or, if blank, should imply the current feed.

I don't have any issues with the <replies> element although I think it would 
be nice to show examples of the two main use cases: namely the equivalent of 
RSS <comments> (basically type="text/html") and the RSS <wfw:commentRSS> 
extension (type="application/atom+xml").

For now I'm going to ignore all the other little issues I have with the 
proposal on the off chance that you come around to my way of thinking. Once 
you throw out inReplyToDereferenceable the whole thing becomes a lot simpler 
and most of those problems should solve themselves.

Regards
James

James M Snell wrote:
> At some point over the next couple of days, a slightly modified version of 
> the comments extension draft [1] will be published.  The moment it 
> become the stable version.  After the Atom Protocol work completes, I will 
> submit the stable version of the draft as a standards track RFC.

---

From: James M Snell <[email-masked]>
Date: Thu, 27 Oct 2005 10:24:50 -0700

Hmm.. I think what this boils down to is a question about whether or not 
the replies extension really does need to support replies to non-Atom 
resources at all.  I can see it both ways.  I definitely understand 
where you are coming from, but I also don't want to have to look in two 
different places for the same basic type of information if the only 
difference is what data format is being referenced. 

Let me stew on this.  If you have any specific language you'd like to 
see in the spec, please go ahead and send it my way.

- James

James Holderness wrote:

>
> Sorry for the delay in commenting, but I only got around to looking at 
> this in detail today.
>
> Other than a few areas that I think need clarification in the wording, 
> my main problem with this proposal is the dereferenceable in-reply-to. 
> While I can see why a feed producer may want to include it, I don't 
> see how an Atom processor can do anything useful with it (which 
> couldn't be done just as easily with existing elements). And if it's 
> not of any use, it seems to be that it's just taking up space and 
> complicating the spec.
>
> The easiest way to explain my position is with some use cases. Let's 
> say you wanted to reply to a particular item in another Atom feed:
>
> <thr:in-reply-to
> button/link/whatever allowing the user to subscribe to the source feed 
> (if he isn't already).
>
> If the item being replied to is in the same feed as the reply then the 
> idea is pretty much the same except no source attribute is required. 
> That's all good.
>
> Now let's say I wanted to reply to a particular item in an RSS feed. 
> Here's what I'd expect:
>
> <link
>  rel="related"
>  type="text/html"
> You could use an in-reply-to tag, but it's not going to be any more 
> useful to me than that (in some cases, less useful). Even with an 
> idref of some sort, I still can't thread such a reply. The original 
> article can't link to my reply as part of its own threading system and 
> nobody reading the original thread can reply to my reply and still 
> have it be part of the original thread.
>
> The bottom line is that it's really not part of a thread - it's a 
> completely separate message that is merely related to the original. In 
> fact, if you were to represent that link as a <thr:in-reply-to> 
> element, the best I could do as a client is convert it into a 
> "related" link or a "via" link.
>
> Basically what it comes down to is this. I think <thr:in-reply-to> 
> should be reserved for threading of atom entries only. Any other 
> replies should be referenced with a "related" or "via" link element. 
> There's no need for a type since it should always be 
> "application/atom+xml". The source should always point to an Atom feed 
> or, if blank, should imply the current feed.
>
> I don't have any issues with the <replies> element although I think it 
> would be nice to show examples of the two main use cases: namely the 
> equivalent of RSS <comments> (basically type="text/html") and the RSS 
> <wfw:commentRSS> extension (type="application/atom+xml").
>
> For now I'm going to ignore all the other little issues I have with 
> the proposal on the off chance that you come around to my way of 
> thinking. Once you throw out inReplyToDereferenceable the whole thing 
> becomes a lot simpler and most of those problems should solve themselves.
>
> Regards
> James
>
> James M Snell wrote:
>
>> At some point over the next couple of days, a slightly modified 
>> version of the comments extension draft [1] will be published.  The 
>> moment it publishes will kick off a two week Unofficial Last Call 
>> period for the spec.  The spec has been stable of the past two months 
>> with no major issues raised.  Please review the draft.  After two 
>> weeks I will review any received feedback and, if appropriate, cut a 
>> new draft which will become the stable version.  After the Atom 
>> Protocol work completes, I will submit the stable version of the 
>> draft as a standards track RFC. 
>
>
>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 27 Oct 2005 20:33:41 +0200

* James Holderness <[email-masked]> [2005-10-27 16:40]:
> I don't see how an Atom processor can do anything useful with
> it (which couldn't be done just as easily with existing
> elements). And if it's not of any use, it seems to be that it's
> just taking up space and complicating the spec.

+1, which won’t surprise anyone.

I managed to miss the fact that this extension cannot be used in
non-Atom documents, otherwise I’d have argued along these lines
before, though I doubt I would have managed anything nearly as
coherent.

One might argue that removing the Atom-specifity would be another
way out of the current dilemma, but measured against the points
you make it would feel to me like a mistake.

We started with a simple hack – arguably too simple – that
somehow grew into trying to be everything to everyone. In the
process it lost of a lot of semantic “hardness.” This is the main
reason I was never very happy with the dereferencable links; I
still can’t explain what I mean as abstractly as I think about
it, but your explanation for why they’re not useful is concrete
demonstration.

In any case, I would be elated to see this extension shed a lot
of weight and go back to addressing a clearly bounded purpose.

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