Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt

2005-07-21 Thread Thomas Broyer


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.

2005-07-21 Thread Graham


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.

2005-07-21 Thread Graham



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.

2005-07-21 Thread A. Pagaltzis

* 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

2005-07-21 Thread James M Snell


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

2005-07-21 Thread A. Pagaltzis

* 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

2005-07-21 Thread James M Snell


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

2005-07-21 Thread A. Pagaltzis

* 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/