Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
Antone Roundy wrote: On Wednesday, July 20, 2005, at 11:44 AM, Thomas Broyer wrote: I was actually wondering why non-stateful feeds couldn't have archives: in the This month's Top 10 records feed, why couldn't I link to Last month's Top 10 records? If this kind of links are not dealt within feed-history, then I suggest splitting the draft into two (three) parts: 1. fh:stateful: whether a feed is stateful or not 2. fh:prev: state reconstruction of a stateful feed 3. (published later) fh:: link to archives of a non-stateful feed (no, I actually don't want such a split, I'd rather deal with the 3. in feed-history, no matter how) If we want to solve this issue using a distinct element (fh:prev if fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still needed? The presence of fh:prev would be equivalent to fh:stateful=true, the presence of fh: would be equivalent to fh:stateful=false, the absence of both fh:prev and fh: would be equivalent to the absence of fh:stateful, and the presence of both fh:prev and fh: would be an error. This is off course true only if fh:prev must be accompanied by fh:stateful=true. The question is: is it useful to have fh:stateful if you have no link to any kind of archive? I would think that rather than fh:stateful=true | false, it might be more useful to have (with a different element name, and perhaps different values) fh:what-kind-of-feed-is-this=sliding-window | snapshot | ???. If it's a sliding-window feed, fh:prev points to the previous sliding window. If it's a snapshot feed, then fh:prev points to the previous snapshot. fh:what-kind-of-feed-is-this might have a default value of sliding-window. +1 and with the addition of fh:prev/@updated (and an optional fh:prev/@title, see below), it turns feed-history to a really cool extension! We could also add some more hints about fh:prev processing depending on fh:what-kind-of-feed-is-this: * if the value is sliding-window, an Atom Processor MAY reconstruct the feed state automatically without user interaction * if the value is snapshot, an Atom Processor SHOULD NOT retrieve archive snapshot feeds unless told by the user (e.g. showing a link or button using fh:prev/@title as the label); when presented to the user, entries in the retrieved snapshot feed SHOULD replace any entry from within another snapshot (e.g. Last Month's Top 10 records should replace This Month's Top 10 records). fh:prev/@title could be used on sliding-window feeds to indicate the title of the latest entry in the previous feed (just like blog homepages sometimes link to the previous entry using its title). fh:prev would look like: fh:prev updated=2005-06-30T23:55:30 title=Last Month's Top 10 records http://example.net/archives/june.atom/fh:prev -- Thomas Broyer
Re: Notes on the latest draft.
On 21 Jul 2005, at 4:43 am, James Cerra wrote: In an XSLT-based Atom-to-XHTML processor, that is a large cost when HTML includes many many many entities. At least, I think so and have ignored the problem because I can't think of a good way to solve it. Yes, but your proposed solution just requires people at the other end of the chain to do the hard work. A common theme in the design of Atom is minimizing the amount of work that must be done by publishers (of which there are many) vs the amount of work done by processing tools (of which there are few, and which are easier to turn into common libraries). Graham
Re: Notes on the latest draft.
On 21 Jul 2005, at 7:29 pm, James Cerra wrote: Graham, Yes, but your proposed solution just requires people at the other end of the chain to do the hard work. A common theme in the design of Atom is minimizing the amount of work that must be done by publishers (of which there are many) vs the amount of work done by processing tools (of which there are few, and which are easier to turn into common libraries). You are probably correct. However... Aren't HTML's character references harder for publishing software to produce compared with HTML numeric references? After all, producing numeric references requires a simple fast algorithm and no lookup table. Thus, depreciating HTML character references makes it _easier_ to publish Atom code as well. Not if the HTML in the publishers database already contains named references, and/or users are regularly submitting HTML that contains named references. The only feed producer software that probably likes HTML character references above all else are human hands. And if humans are writing their feeds by hand, then. Feeds a generally a small facet of a much larger publishing system or process, that yes, includes humans. Graham
Re: Notes on the latest draft.
* James Cerra [EMAIL PROTECTED] [2005-07-21 20:45]: Aren't HTML's character references harder for publishing software to produce compared with HTML numeric references? […] The only feed producer software that probably likes HTML character references above all else are human hands. And if humans are writing their feeds by hand, then.. :-o Well, the feed could still be autogenerated even though a human is writing HTML by hand. Most weblogging systems allow the author to write his post as HTML. In the simplest case, a feed of such entries would be automatically generated but would still contain human-authored HTML. (Of course, I'm probably the loser who would actually write my own feeds by hand! :-)) Not really… :-) I run my weblog by editing a single Atom (0.3 as of yet, need to convert…) feed that contains all entries ever, from which a stylesheet generates the public feed and all the webpages. But I never need to write any entities, since that file is UTF-8 and I edit it with gvim. (Insert “UTF-8 rocks” fanboy praise.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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/
