Subject: Updated Comments Draft (getting closer)

From: James M Snell <[email-masked]>
Date: Mon, 08 Aug 2005 22:10:56 -0700

I've updated the draft of the comments extension.  I think this is just 
about ready to submit as an I-D. 

  http://www.snellspace.com/public/draft-snell-atompub-feed-thread-00.txt

The major change is a refactoring of the in-reply-to and replies-source 
following the extensive discussion here on the list.

  <!-- originalfeed.xml -->
  <feed xmlns="http://www.w3.org/2005/Atom">
    ...
    <link rel="replies"
          type="application/atom+xml"
          href="http://www.example.com/myotherfeed.xml" />
    <entry>
      <id>tag:example.com,2005:1</id>
      ...
    </entry>
  </feed>

  <feed xmlns="http://www.w3.org/2005/Atom">
    ...
    <entry>
      <id>tag:example.com,2005:2</id>
      <in-reply-to
        xmlns="http://purl.org/syndication/thread/1.0/"
        id="tag:example.com,2005:1"
        type="application/atom+xml"
        src="http://www.example.com/originalfeed.xml" />
    </entry>
    <entry>
      <id>tag:example.com,2005:3</id>
      <in-reply-to
        xmlns="http://purl.org/syndication/thread/1.0/"
        href="http://www.example.com/entries/1.atom"
        type="application/atom+xml" />
    </entry>
  </feed>

The second feed illustrates the two forms of the in-reply-to element.  
The dereferenceable form uses the href attribute to locate the entity 
being responded to.  The nondereferenceable form uses a combination of a 
required id attribute and an optional src attribute.

I'll likely go ahead and submit this as an I-D in the morning.

As always, comments welcome.

- James

---

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

* James M Snell <[email-masked]> [2005-08-09 07:25]:
> The second feed illustrates the two forms of the in-reply-to
> element. The dereferenceable form uses the href attribute to
> locate the entity being responded to.

I am still strongly -1 on making the ID optional. Why do you want
to do that?

What scenario exists wherein it would be *more* desirable to
provide *only* a dereferencable location but *not* an ID? When
would it be *wiser* to *rely* on a pointer to a resource which is
always in danger of voiding, irrecoverably breaking the
connection from a reply to its parent?

The ID is REQUIRED in Atom entries. Given this, is there any
*cost* to requiring its inclusion when specifying in-reply-to? I
can’t see any.

To me, making the option available seems like requiring content
producers to make a choice about something their consumers will
never benefit from but may sometimes be harmed by – while
burdening consumer implementors with an extra conditional to
implement support for a useless option, and possibly requiring
them to sometimes fetch representations over the network to even
decide how to thread things.

If you can give me just one example of a scenario where omitting
the ID is beneficial, I’ll concede the point. Otherwise, I
maintain that this is a mistake. Options have a cost. They should
not be provided just for the sake of having them.

And sorry that I keep bludgeoning you. :-) I hope you can see
that my arguments are sound – or show me that they’re not. (After
all, I was just as wrong during half the previous discussion…)

> The nondereferenceable form uses a combination of a required id
> attribute and an optional src attribute.

I’d really like this to include an atom:link[@rel='related']
pointing to the source to encourage its provision.

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

---

From: Eric Scheid <[email-masked]>
Date: Thu, 11 Aug 2005 15:15:11 +1000

> connection from a reply to its parent?

scenario: I'm reading some feed I've subscribed to, and hit an entry which
is a reply to someone else's posting elsewhere. I'm not subscribed to that
other feed. I want to read it. There doesn't exist any atom:id resolvers
(yet). The author neglected to include a direct link. How do I get there?

> can¹t see any.

Are authors only going to reply to Atom feed publishers? Are they going to
avoid replying to RSS feeds, or to statements on some generic HTML page (or
even PDF document)? Requiring an ID when an ID may not be available will
mean not being able to create in-reply-to links to non-Atom resources.

e.

---

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

The simple answer is that not everything I may want to reply too will 
have an ID I can reference.  Suppose that what I'm responding to is an 
item in an RSS feed that does not contain a guid element?  All I have to 
go off of is the URL of the RSS feed or the RSS item's link element... 
neither of which are actual ID's.

---

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

* James M Snell <[email-masked]> [2005-08-11 08:00]:
> Suppose that what I'm responding to is an item in an RSS feed
> that does not contain a guid element?  All I have to go off of
> is the URL of the RSS feed or the RSS item's link element...

Ugh.

Sigh.

Yeah, okay.

I can see that.

Can we still include language that if it’s an Atom entry being
replied to, the atom:id of the original entry is REQUIRED?

Also, that if it’s an RSS feed, then using the GUID value if
provided is strongly encouraged? (I’d like to make that
RECOMMENDED, but that’s too strong a requirement for reliance on
an OPTIONAL feature… sigh.)

Sigh… bleh. I hope one day we can forget about RSS… :-(

Regards,

---

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

* Eric Scheid <[email-masked]> [2005-08-11 07:25]:
> > provide *only* a dereferencable location but *not* an ID?
> > When would it be *wiser* to *rely* on a pointer to a resource
> > which is always in danger of voiding, irrecoverably breaking
> > the connection from a reply to its parent?
> 
> scenario: I'm reading some feed I've subscribed to, and hit an
> entry which is a reply to someone else's posting elsewhere. I'm
> not subscribed to that other feed. I want to read it. There
> doesn't exist any atom:id resolvers (yet). The author neglected
> to include a direct link. How do I get there?

How is that an argument for omitting the ID? It’s an argument in
favour of including a source link, but both forms provide for
a way to store this information.

> Are authors only going to reply to Atom feed publishers? Are
> they going to avoid replying to RSS feeds, or to statements on
> some generic HTML page (or even PDF document)? Requiring an ID
> when an ID may not be available will mean not being able to
> create in-reply-to links to non-Atom resources.

Yeah; point conceded, as I already wrote to James. And as I said
there, I’d still like the ID to be REQUIRED when replying to Atom
entries.

Regards,

---

From: Justin Fletcher <[email-masked]>
Date: Thu, 11 Aug 2005 15:49:46 +0100 (BST)

> connection from a reply to its parent?

Any scenario where the document being referenced is not Atom. If the
comments specification were to restrict itself to just discussion about
the Atom community then that's both very insular and hardly likely to
encourage anyone to contribute to it.

Consider you have a news website that gives you a page with text in it.
You want to reply to it. They don't have an Atom feed. Do you give up on
ever commenting on their text because you can never reference it ? Do you
comment on it but omit any linking details ? Do you complain to the
website author to add an Atom feed because otherwise you can't refer to it
on your weblog ?

There are many document forms which have identifiers to locate them
uniquely in the world (Atom id, RSS guid, RFC2822 mid, MIME cid, book
isbn, etc), but there are also many document forms which have no unique
identifier (HTML documents, PDF documents, physical memos, conversations
in the pub (!), newspaper articles, etc).

To preclude refering to non-id'd documents would be restricting the
specification to only allowing Atom people to talk about Atom people.

By all means require any reference to a Atom document to supply an
identifier, but requiring it on all references would make it impossible to
fulfill on some documents.

-- 
Gerph <http://gerph.org/>
... Want to cry for you. Would it do any good ?

---

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

* Justin Fletcher <[email-masked]> [2005-08-11 17:10]:
> By all means require any reference to a Atom document to supply
> an identifier, but requiring it on all references would make it
> impossible to fulfill on some documents.

Yeah; again, I’ve conceded the point. I still don’t particularly
like this reality we’re dealing with, but unfortunately, there’s
only one of those…

Regards,

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 12 Aug 2005 23:41:28 +0200

James M Snell wrote:
> item in an RSS feed that does not contain a guid element?  All I have 
> to go off of is the URL of the RSS feed or the RSS item's link 
> element... neither of which are actual ID's.
 From your draft's abstract:

   This memo presents a mechanism that allows feeds publishers to
   express threading relationships between entries and feeds.

And from your draft's introduction section:
   This document specifies a mechanism that allows the expression of
   threaded discussions within the Atom Syndication Format ([I-D.ietf-
   atompub-format]).

As I read it, your proposal is about enabling threading in Atom to allow 
aggregators to present entries in a tree form.

If you want to comment on a non-Atom resource, create a new link/@rel 
value or use a link[@rel="related"] or link[@rel="via"] or something 
like that.

So a strong +1 to making the id REQUIRED.

-- 
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 13 Aug 2005 02:54:00 +0200

* Thomas Broyer <[email-masked]> [2005-08-12 23:55]:
> As I read it, your proposal is about enabling threading in Atom
> to allow aggregators to present entries in a tree form.
> 
> If you want to comment on a non-Atom resource, create a new
> link/@rel value or use a link[@rel="related"] or
> link[@rel="via"] or something like that.
> 

You have a point. Hmm.

Regards,