[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Anatoly Vorobey <mellon@xxxxxxxxx> writes:
> Since yesterday there's more than a million active Atom 0.3 feeds at
> http://www.livejournal.com/users/[username]/data/atom . They should
> all conform to the latest 0.3 draft. Anyone is welcome to use them,
> and if you find any problem with their compliance or any suggestions
> for improvement, please drop me a line.
In looking at some feeds I notice that all the <content>s are the
first N characters of the post.
A couple of things, mostly orthogonal and spec related, not particular
to the LJ feeds:
1) the 0.3 draft is missing the @rel attribute for <content>.
content's @rel has been on the wiki forever and I recall it was
pointed out after an earlier draft
1a) the LJ feeds have rel="fragment", which is correct in that it
means "this is not a complete entity resource" (which would mean
<head> or <body> in an Atom archive of a standalone web page, for
example), but may really have been used to incorrectly per:
2) the LJ feeds are using <content> where it seems they should be
3) these summaries are a) system-generated, not human-written; b)
excerpts, as opposed to a summarization, abstract, or paraphrase.
I think those are important distinctions. Possible @rel's might be
"excerpt", "startswith", in contrast to "abstract" or the light
4) in Mark Nottingham's notes on the 0.3 draft, he suggests
treating Content structures more like <link>, in that there's only
one <content>, with well-known attributes, and using different @rel
attributes to indicate what the content is for (body content,
summary, copyright, title, etc.). Food for thought, and an
alternative to (2).
4a) note that when SSFF is used, consumers will treat all feed
content as "advisory", and defer to the entry URI for full