Re: Latest on the comments extension
James M Snell wrote:
/in-reply-to provides the atom:id (not dereferencable) of an
original atom:entry and may appear within atom:feed or
atom:entry. in-reply-to on the feed level indicates that all
of the entries within the feed are considered replies to the
identified atom:entry.
Is it legal if it appears at both levels? And what does it mean
then?
Yes. If the entry level link has the same URI as the feed level link,
there is no effect... it's basically just redundant data. If the entry
level link specifies a different URI, then it's basically an assertion
that the entry is a response to two different entries. If all of the
entries within a feed are replies to the same entry, putting the
in-reply-to at the feed level simply gives you a shortcut the same way
that putting atom:author elements at the feed level rather than entry
level does.
e.g.
1.
!-- legal but redundant --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url1} /
/entry
/feed
2.
!-- equivalent to #3 below --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
3.
!-- equivalent to #3 below --
feed
entry
link rel=.../in-reply-to href={url1} /
link rel=.../in-reply-to href={url2} /
/entry
/feed
#2 is not how atom:author inheritance works (assuming there is some kind
of atom:author inheritance, which is not established). I'd prefer #2 to be
equivalent to this:
feed
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
That is, the set of entry level links overrides the set of feed level links.
If I understand correctly, .../root tells you where to find the entry
identified with .../in-reply-to. How are you dealing with multiple
in-reply-to?
link rel=.../root href=feeda.xml /
link rel=.../root href=feeda.xml /
link rel=.../in-reply-to href=tag:entry1 /
link rel=.../in-reply-to href=tag:entry2 /
If I misunderstood, what is .../root for?
--
Thomas Broyer
Re: Latest on the comments extension
Thomas Broyer wrote:
James M Snell wrote:
/in-reply-to provides the atom:id (not dereferencable) of an
original atom:entry and may appear within atom:feed or
atom:entry. in-reply-to on the feed level indicates that all
of the entries within the feed are considered replies to the
identified atom:entry.
Is it legal if it appears at both levels? And what does it mean
then?
Yes. If the entry level link has the same URI as the feed level link,
there is no effect... it's basically just redundant data. If the entry
level link specifies a different URI, then it's basically an assertion
that the entry is a response to two different entries. If all of the
entries within a feed are replies to the same entry, putting the
in-reply-to at the feed level simply gives you a shortcut the same way
that putting atom:author elements at the feed level rather than entry
level does.
e.g.
1.
!-- legal but redundant --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url1} /
/entry
/feed
2.
!-- equivalent to #3 below --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
3.
!-- equivalent to #3 below --
feed
entry
link rel=.../in-reply-to href={url1} /
link rel=.../in-reply-to href={url2} /
/entry
/feed
#2 is not how atom:author inheritance works (assuming there is some kind
of atom:author inheritance, which is not established). I'd prefer #2 to be
Yeah, you're right. bad analogy.
equivalent to this:
feed
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
That is, the set of entry level links overrides the set of feed level links.
Gotta think about this a bit more. This may be the better approach.
If I understand correctly, .../root tells you where to find the entry
identified with .../in-reply-to. How are you dealing with multiple
in-reply-to?
link rel=.../root href=feeda.xml /
link rel=.../root href=feeda.xml /
link rel=.../in-reply-to href=tag:entry1 /
link rel=.../in-reply-to href=tag:entry2 /
If I misunderstood, what is .../root for?
.../root is simply a link back to feeds that may contain root level
entries (e.g. the entries being responded to). In the example, the two
in-reply-to links could reference entries in either of the two linked
root feeds. It's up to the implementation to figure out exactly how to
handle it.
Again, I'm still stewing over all this so if you have any specific
suggestions on how to handle it better, please let me know.
- James
Latest on the comments extension
I've been continuing to tweak the comments extension and believe that I am nearing a stable enough version to draft up the I-D. Here's what I've got currently: http://www.snellspace.com/wp/?p=194 There are three link relations: * http://purl.org/syndication/thread/1.0/comments * http://purl.org/syndication/thread/1.0/root * http://purl.org/syndication/thread/1.0/in-reply-to /comments provides the URL (dereferencable) to an Atom feed that contains comment entries and may appear within atom:feed and/or atom:entry /root provides the URL (dereferencable) to the Atom feed that contains the original entries and may appear within atom:feed and/or atom:entry /in-reply-to provides the atom:id (not dereferencable) of an original atom:entry and may appear within atom:feed or atom:entry. in-reply-to on the feed level indicates that all of the entries within the feed are considered replies to the identified atom:entry. all of these link relations may appear more than once (e.g. an entry can be a reply to multiple entries from multiple feeds. Example 1: A weblog with a main feed and a comments feed Feed A: Main entry feed Feed B: Comments feed !-- Feed A -- feed ... link rel=http://purl.org/syndication/thread/1.0/comments; href=http://example.com/feedb.xml; / entry idtag:entry:1/id ... /entry /feed !-- Feed B -- feed ... link rel=http://purl.org/syndication/thread/1.0/root; href=http://example.com/feeda.xml; / entry idtag:entry:1:1/id link rel=http://purl.org/syndication/thread/1.0/in-reply-to; href=tag:entry:1 / ... /entry /feed Example 2: A post on one weblog responds to a post on another weblog Feed A: Blog 1 feed Feed B: Blog 2 feed !-- Feed A -- feed ... entry idtag:blog-a:entry:1/id ... /entry /feed !-- Feed B -- feed ... entry idtag:blog-b:entry:1/id link rel=http://purl.org/syndication/thread/1.0/root; href=http://blog-a.com/feeda.xml; / link rel=http://purl.org/syndication/thread/1.0/in-reply-to; href=tag:blog-a:entry:1 / ... /entry /feed Feedback requested. - James
Re: Latest on the comments extension
* James M Snell [EMAIL PROTECTED] [2005-07-21 23:15]: Feedback requested. I like it so far; comments follow (no pun intended). /root provides the URL (dereferencable) to the Atom feed that contains the original entries and may appear within atom:feed and/or atom:entry Why is this restricted to being an Atom feed? Shouldn’t @type govern the precise meaning? Should linking to other kinds of resources, such as a weblog with the appropriate autodiscovery tags in its HTML or to a FOAF file, be outlawed? If not, are there any SHOULD/MUST requirements for linked resources? /in-reply-to provides the atom:id (not dereferencable) of an original atom:entry and may appear within atom:feed or atom:entry. in-reply-to on the feed level indicates that all of the entries within the feed are considered replies to the identified atom:entry. Is it legal if it appears at both levels? And what does it mean then? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Latest on the comments extension
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-07-21 23:15]:
Feedback requested.
I like it so far; comments follow (no pun intended).
;-)
/root provides the URL (dereferencable) to the Atom feed that
contains the original entries and may appear within atom:feed
and/or atom:entry
Why is this restricted to being an Atom feed? Shouldn’t @type
govern the precise meaning? Should linking to other kinds of
resources, such as a weblog with the appropriate autodiscovery
tags in its HTML or to a FOAF file, be outlawed? If not, are
there any SHOULD/MUST requirements for linked resources?
The restriction is to make the link predictable and keep the spec
simple. For instance, if I linked to anything but an Atom feed, what
would in-reply-to link to?
/in-reply-to provides the atom:id (not dereferencable) of an
original atom:entry and may appear within atom:feed or
atom:entry. in-reply-to on the feed level indicates that all
of the entries within the feed are considered replies to the
identified atom:entry.
Is it legal if it appears at both levels? And what does it mean
then?
Yes. If the entry level link has the same URI as the feed level link,
there is no effect... it's basically just redundant data. If the entry
level link specifies a different URI, then it's basically an assertion
that the entry is a response to two different entries. If all of the
entries within a feed are replies to the same entry, putting the
in-reply-to at the feed level simply gives you a shortcut the same way
that putting atom:author elements at the feed level rather than entry
level does.
e.g.
1.
!-- legal but redundant --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url1} /
/entry
/feed
2.
!-- equivalent to #3 below --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
3.
!-- equivalent to #3 below --
feed
entry
link rel=.../in-reply-to href={url1} /
link rel=.../in-reply-to href={url2} /
/entry
/feed
- James
Re: Latest on the comments extension
* James M Snell [EMAIL PROTECTED] [2005-07-22 01:25]: For instance, if I linked to anything but an Atom feed, what would in-reply-to link to? Still atom:id values. Presumably, any resource linked to is associated, by whatever means, to the Atom feed containing the entry being replied to. I don’t know what behaviour would be most sensible for cases where it’s not an Atom feed and I’m not advocating trying to specify any. I just think it’s a good idea to say that the specified expectation, ie that it’s the Atom feed where the entry being replied to originated, applies only when @type='application/atom+xml'. That way, if someone else figures out a sensible thing to do for other cases in the future, they can extend the same relation rather than needing to specify a new one. If the entry level link specifies a different URI, then it's basically an assertion that the entry is a response to two different entries. Ah, the feed-level link simply inherits. Good idea, I like that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
