Summary of thoughts and questions:
*** 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
