I also have a question regarding the fh:incremental element. While the spec
says it SHOULD occur, and it MAY be assumed true if the document contains
a fh:prev element, it doesn't say how to interpret a document which has
neither fh:incremental nor fh:prev (which is exactly the status of most
My preference would be for a client initiated approach that automatically
took effect on September the 19th.
A conforming client SHOULD perform an HTTP request for the feed with the
Accept-Language header set to en-pirate (or whatever the standard RFC 3066
language tag for the pirate
If you read the help on that error message you'll see it's quoting directly
from section 3.3 of the Atom spec:
Date values SHOULD be as accurate as possible. For example, it would be
generally inappropriate for a publishing system to apply the same timestamp
to several entries which were
Marking entries as having no rank sounds like a nice idea, but I don't think
it's feasible in the long run. In order to erase ranking effectively from
previous entries, the content provider needs to double their feed size
potentially. And if a user misses out on a rank update they could end
I had considered something along those lines, but it seemed to me to be a
bit vague. I suspect it would produce adequate results in the majority of
cases, but I'd prefer something that gave the content provider finer
control. I like the idea of being able to say exactly where in a feed an
James M Snell wrote:
This could all get rather complicated very quickly. My primary objective
is to address known use cases for ordered feeds (my netflix queue feed[1]
for example), most of which are structured as complete datasets that are
non-incremental in nature.
I realise that this
I know the Atom working group seemed to be against reusing dublin core in
the core Atom spec, but since this is an extension, were dcterms:valid
and/or dcterms:available ever considered as alternatives? From my
understanding they appear to be describing essentially the same thing.
I don't
James M Snell wrote:
the dcterms:valid element is not quite expressive enough in that it is
limited to dates (and does not include the time).
Are you sure about that? The example here
(http://web.resource.org/rss/1.0/modules/dcterms/#valid) certainly shows a
time range, and the
James M Snell wrote:
Also, the description and examples of the Date element here:
http://www.dublincore.org/documents/usageguide/elements.shtml
/Element Description:/ A date associated with an event in the life cycle
of the resource. Typically, Date will be associated with the creation or
Just a follow-up on the representation of Date Ranges in dublin core. I was
under the mistaken impression that you needed to use a DCMI Period encoding
to represent a date range, but apparently ISO 8601 time intervals are
perfectly valid. In order to clarify the situation, the DC Date Working
Mark Nottingham wrote:
Thanks for the feedback. As I've explained before, I have a pretty strong
preference for the current design, to make it usable in other formats;
i.e., the scope of this is not just Atom (which is why I'm probably going
to do it as an Individual submission).
At
Luke Arno wrote:
No, it is not wrong to use atom:link in RSS2. There is existing
precedence for this and it really does make a whole lot of sense.
yup.
http://opensearch.a9.com/spec/opensearchresponse/1.1/
for instance.
Also used in the Universal Subscription Mechanism:
Mark Nottingham wrote:
Probably the closest thing to what you want is this proposal:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-
history-04.txt
It has previous, but not next.
It just occurred to me when reading this message that there may be some
advantages to
Thomas Broyer wrote:
atom:rights at feed-level don't apply to its entries, just to the feed as
it stands. If you want to grant/restrict rights at an entry-level, use the
entry-level atom:rights.
Ok, I missed that. For some reason I assumed atom:rights was just a
feed-level element (probably
I'd be in favour of dcterms:valid (preferably restricted in form) for the
following reasons:
* I'm worried that producers of RSS 1.0 feeds would be more likely to use
dcterms:valid and thus consumers would be obliged to support it anyway.
* dcterms:valid has slightly more functionality in
Funny you should say that. When you told me it was part of Atom 0.3 I also
thought to myself that I should have checked that before posting.
Technically you were correct. Version 0.3 of the syndication format doesn't
mention next and prev explicitly, but it does say (in section 3.4.1) that
In case anyone is interested, the OpenSearch Response draft can be found
here:
http://opensearch.a9.com/spec/opensearchresponse/1.1/
The rel values they support include next, previous (not prev), start and
end. They have a note next to each saying This value is pending IETF
registration.
James M Snell:
I would expect anyone who uses RSS 1.0 would be more likely to use
extensions that are well suited to RSS 1.0 and that anyone who uses Atom
1.0 would be more likely to use extensions that are well suited to Atom.
If there is the possibility of cross-over, great, if not, that's
Pascal Philippe wrote:
For example, in a web blog entry, I can have more than one components.
A web blog entry can be, as example, a picture (encoded in base64)
with a text. How can I represent this using the Atom syntax?
If you want the image to appear inline, you can include it as an HTML
A. Pagaltzis wrote:
And deviously, you can inline the image data inside the feed too,
by using a data: URI with one of these methods.
However, shipping blobs around inside a feed is not a bright idea
with the currently common feed use cases.
There's also the problem that Internet Explorer
John Panzer wrote:
If I recall, I believe this is because some people wanted to be
able to package multiple pieces of content together in a single
entry, and other people did not want to have to imply a
requirement for MIME multipart parsing as pat of the Atom
format specification.
Ugh.
My understanding was that if fh:incremental was false the feed document
should be considered a complete replacement for any previous document you
may have received. This would be for things like top 10 lists.
I believe the question being asked here is actually about the entries
themselves
Graham wrote:
On 13 Oct 2005, at 8:02 pm, A. Pagaltzis wrote:
If you want to ship a complete representation, you ship an
atom:entry, and if the resource is empty, then that atom:content
is empty.
If the atom:entry has no atom:content, then that always means
that it is a partial representation
Mark Nottingham wrote:
I agree that it's important to honour the document order; that's what FH
tries to do. I'm a little surprised to hear you say that people thought
that this was previously 'next'; I'd never heard that (but will be happy
to put a note in).
Mark Pilgrim's article on
Subscription feed:
- can contain link/@rel=prev, OR
- can contain fh:incremental = false
I never did understand this. Why is fh:incremental needed here? From a feed
history point of view you either have a history (a prev link is present) or
you don't. That's all an Atom processor needs
Eric Scheid wrote:
I'd prefer that our use of 'prev' and 'next' be consistent with other uses
elsewhere, where 'next' traverses from the current position to the one
that
*follows*, whether in time or logical order. Consider the use of
'first/next/prev/last' with chapters or sections rendered
Eric Scheid wrote:
Ask yourself these questions: which is the first message in this thread,
and if you wanted to understand the thread would you start there, or at
the
most recent entry in this thread and read backwards. Remember that by the
time you've read back to the initial posting there
* Reconstructing a feed should use:
a) a specific relation, e.g., prev-archive
+0
b) a generic relation, e.g., previous
+1
+1 to all
Just a minor grammatical quibble regarding the text for subscribe: the
phrases ending with a preposition seem somewhat awkward to me - in
particular the double to. If you think I'm being overly dogmatic, though,
feel free too ignore.
Possible replacement text:
- Attribute
Tim Bray wrote:
On Oct 20, 2005, at 4:52 PM, Mark Nottingham wrote:
- Attribute Value: subscribe
I'm puzzled by this one. I thought that if you wanted to subscribe to a
feed then, well, you would subscribe to a feed. I must have missed the
discussion. Could someone provide a
Thomas Broyer wrote:
As I already explained, paging is orthogonal to the incremental nature of
a feed. An incremental feed will be chunked as explained in Mark's current
Feed History draft (just use an atom:[EMAIL PROTECTED]previous] instead of the
fh:prev extension element) and a
I'm not sure if I've understood you correctly, but if this could be used as
a hint to the aggregator on how best to process/display the feed then I
think it's a great idea.
For example, knowing that a feed was a collection of images (e.g. a Flickr
feed) would enable the aggregator to
James M Snell wrote:
Ok, now that a number of the other extensions I've been working on are
moving along, it's time to turn my attention to a couple of other ideas
I've been stewing on. One of which is link[rel=sponsored] to indicate
sponsored links / advertisements within feeds.
Not sure
Tim Bray wrote:
On consideration, I am -1 to rel=subscribe. The reason is this: one of
the big potential value-adds Atom brings is a standards- compliant way to
do one-click auto-subscribe, via link rel=self /
. You are proposing to introduce a link rel=subscribe / which
is there to
Antone Roundy write:
If creation time is relevant to the data being searched, then this makes
sense. But what if I want to subscribe to the top 10 Google results for
some keywords I'm trying to optimize my site for (ignoring the fact that
Google doesn't return search results in any feed
Eric Scheid wrote:
Finally, markup design that claims to enforce a specific action is
always questionable. The great virtue of descriptive markup in
general is that the tags tell you not what to do with things but what
they are. So on that basis, rel=current-version or something is
better
Mark Nottingham wrote:
I've replaced subscribe with current; otherwise, these are the
same as in the last round. I think they're ready to go -- any more
comments?
+1 on everything
James M Snell wrote:
1. Can a profile element appear in an atom:feed/atom:source? If so, what
does it mean? I think it should with the caveat that the profile attribute
should only impact the feed and should not reflect on the individual
entries within that feed.
I can't see any particular
Eric Scheid wrote:
The challenge with using alternate to point to files of different types
is that why would someone do (a) when they can already do (b) without
the help of a new extension
(a)
link rel=enclosure type=audio/mpeg
href=http://example.com/file.mp3;
x:alternate
Thomas Broyer wrote:
I beg to differ. I think the incremental state of a feed is very relevant
to paging. If the aggregator does not know that a feed is non-incremental
it will not be able to process the feed document in a meaningful manner.
Yes, but that's orthogonal to paging.
I think I
Perhaps they can, but that wouldn't always be desirable. Consider this
scenario: Somebody writes a program that searches Google, scrapes the
HTML results, and publishes them as an Atom feed. My purpose in
subscribing to the feed is not to be alerted when a new webpage is added
to page
Antone Roundy wrote:
Here's a final option--is it legal? Is it better or worse than (a) in
any ways?
(d)
link rel=enclosure type=audio/mpeg href=http://example.com/
file.mp3
link rel=alternate type=application/ogg href=http://
example2.com/file.ogg /
/link
I'm not completely sure
Antone Roundy wrote:
Interesting. Filling an attribute with a list of URIs doesn't really
appeal to me though.
Me neither. Something feels wrong about that. If you want a concrete reason,
it requires extra parsing whereas everything else would be automatically
parsed by the XML library.
James M Snell wrote:
link rel=enclosure href=http://example.com/softwarepackage.zip;
type=application/zip x:group=software-package nf:follow=no
x:mirror href=http://example2.com/softwarepackage.zip;
title=California Server /
x:mirror href=http://example3.com/softwarepackage.zip;
Sorry for the delay in commenting, but I only got around to looking at this
in detail today.
Other than a few areas that I think need clarification in the wording, my
main problem with this proposal is the dereferenceable in-reply-to. While I
can see why a feed producer may want to include
I'm not a big fan of this either. The count can never be assured of any
accuracy so if I were to display something like this I end up having to try
and explain to my users why it says there are no replies when in fact they
there are 20.
Also, it forces excessive refreshes on the main feed
In the Atom Syndication Format ID, section 4.1.1.1 advises that atom:entry
elements contain a non-empty atom:title element [1]. But it never goes so
far as to make this a MUST requirement or SHOULD suggestion.
However, the Atom Syndication Format Introduction at atomenabled.org quite
James M Snell wrote:
The feed thread draft is a major update that includes a simplification of
the in-reply-to element.
in-reply-to
id=tag:example.org,2005:some-unique-id
href=http://example.com/some-location; /
I really like what you've done with this. I have a couple of
James M Snell wrote:
What is the type of the resource pointed to by the in-reply-to href? It
It's whatever type the server says it is when you GET it (Content-Type
header).
Well ideally you wouldn't want to GET or HEAD every href in order to
determine its type. I'm not positive this is a
Phil Ringnalda wrote:
isn't the author of the feed metadata), I'd claim that an empty feed
shouldn't be required to have an author, since it's only needed for
inheritance down to an entry.
I agree completely. IMHO some of these MUST contain requirements would be
far more appropriate as
A. Pagaltzis wrote:
Given this constraint, do you have a better idea how do address
the following concerns?
• Threading-unaware clients should get at least some information
that allows the user to notice that there’s more to the entry,
even if the user agent remains blissfully unaware of the
Alan Gutierrez wrote:
For commentsRSS, you could convert to:
link rel=replies type=application/rss+xml href={url} /
The one caveat is that the replies link rel has not yet been
registered in the IANA link registry.
Thank you James.
IANA doesn't seem to list application/rss+xml either.
Alan Gutierrez wrote:
you're going to have to make do with application/rss+xml. It's about as
official a type as you can get for an RSS feed, but it's not registered
because it can't be registered.
Okay, I'm curious.
With no stake in the answer, mind you, why can it not be registered?
From
Henry Story wrote:
Does Atom allow there to be multiple parallel renditions of a blog entry
in different languages?
So it is not really possible to put atom entries with the same id and
updated time stamp in a feed (without a SHOULD level violation) even if
they are translation of each
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-12-22 19:30]:
To indicate that the feeds were translations of one another, a
new translation link rel could be established on the feed
level
Is that even necessary? Wouldn’t @rel='self' already work here?
I would have thought
Henry Story wrote:
I still think it would be good to be able to have to entries in one feed
and be able to state that they are translations of one another. I don't
think that putting them in different feeds is going to cover all the
cases. See below.
Fair enough. Simon certainly seemed
David Powell wrote:
link rel=alternate
type=application/atom+xml
hreflang=fr
x:id=french_entry_id /
What do you think?
I assume that there is an href missing from that?
Actually no. At least not necessarily. That was to indicate the special case
where the link was pointing to an entry
James M Snell wrote:
This is mainly coming up in the context of tagging. I want to be able to
specify a tag and a URI that can be used to request a list of other items
associated with that tag.
Having an href attribute on the Category element strikes me as an
obviously useful thing that we
James Yenne wrote:
I'm led to believe there is some controversy here. James' description is
what I would expect, and seems straight-forward enough. Is there any
thing
more to this?
There are a couple of options for an aggregator author. They can mark an
entry as having changed when 1)
Stephane Bortzmeyer:
OP. In Atom, it seems to me that 2) is the only reasonable choice (1
or 3 would require to store the content - or at least a hash - and, if
applied blindly, would create many false positives since a simple
reformatting of the XML would trigger a change).
Read my response
Eric Scheid wrote:
Is this a valid atom entry?
entry
[...elided...]
summarya snippet of foo xml/summary
content type=application/foo+xml
foo:thing xmlns:foo=http://xmlns.com/foo/0.1/;
foo:nameKing George/foo:name
/foo:Person
Eric Scheid wrote:
But I'm not so sure it's valid now, because of the SHOULD clause below:
I suppose technically it is valid since a SHOULD is a recommendation not a
requirement, but you'd need a very good reason for not following that
recommendation.
For example, an OPML document
Eric Scheid wrote:
then you're not going to like what I was thinking of doing ... posting
atom:category / chunks to an APP/media collection, such that the media
collection entry might look like this (no typos this time, I hope)...
entry
...
content type=application/atom+xml
Eric Scheid wrote:
On 17/1/06 2:21 AM, James Holderness [EMAIL PROTECTED] wrote:
the media resource is supposed to be stored external to
the collection feed and referenced via a content src link
hmmm ... premature optimisation due to common use case of binary content?
Possibly
Graham Parks wrote:
On 16 Jan 2006, at 4:59 pm, James Holderness wrote:
Now since Atom 0.3 is still a whole lot more widely used than Atom 1.0,
you can be fairly sure than anyone that bothers to handle XML content at
all will be capable of handling type=application/xhtml+xml containing
A. Pagaltzis wrote:
No. RFC4287 does not merely recommend it, it RECOMMENDS it.
I don’t know about you, but I consider a SHOULD to be pretty
strong language.
I consider it as strong as its definition which clearly says: there may
exist valid reasons in particular circumstances to ignore a
A. Pagaltzis wrote:
Aggregators which process @type='application/xhtml+xml' as if it
was @type='xhtml' are in error. Period.
To recommend conflating `xhtml` and `application/xhtml+xml` is to
deprive content producers of precise expressibility of intent.
So what is your intent? What do you
Robert Sayre wrote:
Not true. Atom *recommends* that the page content is a full standalone
web
page. It's not a requirement.
Atom also says that you should expect it not to work.
You shouldn't expect any MIME types to work, or specifically MIME types that
aren't full standalone documents?
Antone Roundy wrote:
I'm all for consuming applications that want to be really smart checking
whether the content of content type=application/xhtml +xml is a
fragment or a complete document and handling either, but if your content
is an xhtml document fragment, is there any reason at all
Robert Sayre wrote:
Heh. Twice in one day. That's an unrelated bug.
I suspected it was probably unrelated. I tried to reproduce it with a
simpler case and it didn't have any problems subscribing. I just didn't have
time to experiment any more. If you want another problem to investigate, try
David Powell wrote:
Assuming that the document's /html/head section is irrelevant and
discarding it, even when the publisher has specifically used non-core
types to send the full document, is second-guessing the user though.
Fair enough, but you could also say that anyone filtering out
James M Snell wrote:
First off I wouldn't recommend using XML content at all because I don't
think the aggregator support is very widespread yet. But if you were
-1, bad recommendation. Applications should feel free to use the full
capabilities of Atom content model regardless of current
Graham Parks wrote:
True, but sometimes people have to make decisions based on the limited
information available to them. Knowing that something is quite likely
to work is better than not knowing anything at all.
No it isn't.
Ok. If you like working in the dark I'm not going to try and
A. Pagaltzis wrote:
So what is your intent? What do you expect aggregators to do
with that content?
Really, what I expect them to do with that content is to not fail
to display a full document if a full document is what I provide.
That aggregators attempt to render such full documents inline
Stephane Bortzmeyer wrote:
Is there somewhere a comprehensive survey of the current level of
support in readers, with details for each feature, specially the most
Atom-specific?
There are a couple of basic tests on the Atom wiki [1] including an
updated test. They're not very comprehensive,
Andreas Sewe wrote:
Too bad the values used are inconsistent with XHTML rel values, though,
but then again I probably suffer from syntactic hypersensitivity. ;-)
The value was prev initially, but some people expressed a preference for
previous and I figured it wasn't worth another month of
James M Snell wrote:
Still in experimental stages. Cleaned up a bit and removed the
archived-entry element. Comments requested... particularly from potential
client implementors...
http://www.ietf.org/internet-drafts/draft-snell-atompub-tombstones-01.txt
I'm glad you've brought this up -
James M Snell wrote:
One question: what's a reasonable length of time to keep the deleted-entry
elements in a feed? We don't really want to keep those things around
forever.
Actually I think I probably would recommend keeping them forever. Just treat
them like any other entry. If they fall
James M Snell wrote:
Which leaves us with...
del:deleted-entry
atom:id.../atom:id
del:when.../del:when
del:by.../del:by
del:comment.../del:comment
/del:deleted-entry
I think I've probably mentioned this before, but FWIW I preferred the id and
date as attributes since that's easier
Henry Story wrote:
Just re-reading your mail I think you make a good point that perhaps
translation is the wrong word to use. We would like something more
abstract such as otherLanguageVersion. This made me think that the
word we want is alternate. And then looking at the spec again I
found the
Henry Story wrote:
Presumably one would need to add an x:feed=http://mydomain.com/feed;
attribute for translations of entries that appear in other feeds.
Actually I was thinking just a regular href and type. For example:
link type=application/atom+xml
href=http://mydomain.com/feed;
David House wrote:
We have two options here: give up or serve as text/xml (I guess
the latter won't be too popular). Really, browsers should recognise
application/atom+xml as something they can parse as XML and do so.
I can't understand why so many people want to prevent the browser from
I've been seeing a number of feeds recently using Atom 0.3 with a content
type of text/html and no mode attribute (i.e. the equivalent of
mode=xml). However, the markup in that content is wrapped in a CDATA
section, for example something like this:
content type=text/html
![CDATA[div
Hahaha! It's RSS all over again. In the words of Mark Pilgrim: Here's
something that might be HTML. Or maybe not. I can't tell you, and you can't
guess. :-)
Seriously though, the atom:name element is described as a human-readable
name, so unless your name really is Betrand Cafeacture; that
Sylvain Hellegouarch wrote:
Do you mean that human-readable is equivalent to solely English? Because
as a French, having accents in names is so natural that I see it as human
readable too ;)
No. I mean that the literal sequence of characters e a c u t e ; is not
human-readable (or at least
A. Pagaltzis wrote:
So is this a bug in the content generator (all the feeds I've
seen appear to be using TypePad)
Yes.
or are you supposed to ignore the mode attribute when the
content type is set to text/html and always treat it as
escaped?
No.
Thanks for the confirmation. I was
David Powell wrote:
[Hmm, internal DTD subsets completely fail in IE7's feed reader,
throwing up a friendly error message]
If I remember correctly they considered that a feature. Something to do with
DTDs being a security risk. I'm not sure if this also meant they were
incapable of
A. Pagaltzis wrote:
What I really don’t get is what that `xmlns` attribute is doing
there in the CDATA block of your data sample. Sometimes I wonder
if CDATA should not have been left out of the XML spec; it seems
to create far too much confusion to be worthwhile.
Well if you look at some of
James M Snell wrote:
1. Do I change in-reply-to id=... / to in-reply-to ref=... / ?
I don't know enough to care what you call those attributes. And it's a long
way before we'll go live with anything so if you need to change attribute
names it wouldn't bother me in the least.
2. Do I
Sean Lyndersay wrote:
In my own case (IE7) case, this isn't that big a deal because
we have to grovel in HTML for many other reasons, but I suspect
it'd be pain for other clients.
Looking at the results of the Atom XmlBaseConformanceTests [1] mosts of the
clients tested seemed capable of
Tim Bray wrote:
On Mar 30, 2006, at 9:20 PM, James M Snell wrote:
I would agree that, as a best practice, the xml:base should appear on
the content element, but implementations need to be prepared to use
whatever the in-scope URI is (e.g. if no xml:base is specified, relative
refs in the
A. Pagaltzis wrote:
I’ve been meaning to add some aggressive tests which use xml:base
values that differ drastically from the nearby alternate URIs in
order to smoke out such coincidentally passing tests, as well as
some intentionally evil tests with `type=xhtml` where xml:base
is set on
Eric Scheid wrote:
On 1/4/06 12:24 PM, James Holderness [EMAIL PROTECTED] wrote:
one way would be to use img / instead of a / links, with each test
image
being specific to the test ... that way all one needs to do is read the
feed
and check to see if the text in the image corresponds
an explicit xml:base anyway, so maybe that's
not worth worrying about. I'm not sure though. Should the WG recommend
ignoring Content-Location as a base URI, or should aggregators follow the
RFC exactly as specified?
Regards
James Holderness
Anne van Kesteren wrote:
If `Content-Location` is not usable or can't be used consistent on a
website
(for example, using it for both Atom and HTML content) I suggest we
specify
something that is consistent with what browsers do. And perhaps try to
obsolete the relevant header if possible...
James M Snell wrote:
The Feed Thread draft has been updated.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-07.txt
I am an absolutely terrible proofreader so I'd really appreciate it if
someone could do a quick scan over the current doc to find the typos
that I know must
James M Snell wrote:
Not a proofreading issue, but shouldn't section 5 say something about
DOS attacks using replies links to third party servers? I wouldn't be
surprised if some clients automatically subscribed to all replies links
in a feed even if they were 100MB zip files on a completely
David Powell wrote:
But what would processors do with an atom:link? Atom Protocol uses
edit, there have been calls for a stylesheet. Links aren't
necessarily things that you'd display to users (check HTML out for
examples of that: favicon, P3P, Atom/RSS, GRDDL)
Well if you've got a decent
James M Snell wrote:
a. Status quo. Leave things the way they are in the current draft
+1
b. Drop thr:count and thr:when from the spec.
+0.5
c. Create a new replies extension element
-1
d. Create a supplemental extension element
+0
M. David Peterson wrote:
Are you aware that those of us who read your blog in an aggregator
such as FeedDemon see all the HTML markup? Makes it very hard to read,
and hard to judge whether a particular post is worth leaving the
aggregator for a closer look.
Steven Black | April 14, 2006 09:10
1 - 100 of 141 matches
Mail list logo
