Hi Antoine,
On Nov 30, 2006, at 10:21 AM, Antone Roundy wrote:
Summary of thoughts and questions:
Thanks -- this is incredibly helpful. However, might I suggest a
couple more options?
6) Change expectations, not the spec.
Consumers must poll the feed to inspect the metadata, and Servers
must accept both.
7) Disallow entry-only documents
Require all Atom documents to have a feed wrapper in order to be
parsed properly. This is basically #4 + procrastination. :-)
I'm not saying these are necessarily _good_ options, but I'd like to
be sure that whatever we do propose is superior to either of these;
i.e., is the use of entry-only documents important enough to justify
all this work?
Thanks,
-enp
*** Problems with the status quo ***
A) Consumers don't have enough information (without retrieving the
remote resource) to determine whether to treat a link to an Atom
document as a link to a live feed, a feed archive, or an entry.
(Is it appropriate to poll the link repeatedly? How should
information about the link be presented to the user?)
B) APP servers can't communicate whether they will accept feed
documents or only entry documents.
*** Possible solutions ***
1) Add a type parameter to the existing media type:
+ With the exception of a few details, the documents are all
exactly the same format (does it contain a feed element, or does it
start at the entry element, is it a "live" feed document or an
archive, etc.), so a single media type makes the most sense
(definitely for live feeds vs. archives, less certainly for feeds
vs. entries).
- Some existing applications will ignore the parameter and may
handle links to non-live-feeds inappropriately
- Some existing applications may not recognize application/atom
+xml;type=feed as something appropriate to handle the same way they
handle application/atom+xml now.
? I haven't been following development of the APP, so forgive my
ignorance, but can parameters be included in the accept element?
2) Create (a) new media type(s) (whether like application/atomentry
+xml or application/atom.entry+xml):
+ Applications that currently treat all cases of application/atom
+xml the same would ignore non-feed links until they were updated
to do something appropriate with the new media type.
- Differentiating between live feeds and archives by media type
seems really wrong since their formats are identical. This isn't
as big a negative for entry documents, but it still seems
suboptimal to me.
- If a media type were created for archive documents, would APP
accept including application/atom+xml imply acceptance of archive
documents too? Neither yes nor no feels like a satisfying answer.
3) Use @rel values to differentiate:
- That territory is already a bit of a mess, what with "feed" vs.
"alternate" vs. "alternate feed" vs. "feed alternate" -- why make
it worse?
+ That territory is already a bit of a mess, what with "feed" vs.
"alternate" vs. "alternate feed" vs. "feed alternate" -- why not
work on all these messy problems in the same place?
- That wouldn't help with the APP accept issue.
4) Create a new media type for entry documents, and add a parameter
to application/atom+xml to differentiate between live and archive
feeds (and for any other documents that have the identical format,
but should be handled differently in significant cases).
- Doesn't prevent existing apps that ignore the parameter from
polling archive documents.
+ Does solve the rest of the problems without the negatives of #2
above.
5) Create a new media type for entry documents, and use @rel values
to solve issues that doesn't solve:
+/- Messy territory
If we were starting from scratch, I'd probably vote for #1. Since
we're not, I'd vote for #4 first, and perhaps #5 second, but I'd
have to think about #5 more first.
Antone
