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
passing Atom feeds on to the user's registered feed reader. When a browser
encounters an audio/mpeg link what does it do? It passes it on to the user's
media player. It doesn't try to display a binary dump of the file, or a
waveform image. That would just be stupid. But for some reason people think
it makes more sense to display a page full of XML to the user rather than
letting them view the feed in their aggregator. I just don't get it.
Admittedly if the user doesn't have an aggregator installed, or their
aggregator hasn't registered the application/atom+xml media type, then a
save dialog is not particularly useful. At that point it may be more useful
for the browser to try and display the XML inline. But that is a fallback
situation that should only be considered if there isn't a registered handler
for the Atom media type.
John Panzer wrote:
(1) All links from within feeds go to a resource of type
"application/atom+xml".
(2) Header links (<link rel...>) in web pages to to a resource as in #1.
(3) Feed links displayed in web pages, which a user in a web browser might
click on, go to a resource of type "application/xml", which contains
exactly the same XML that would be contained in the Atom feed resource of
type "application/atom+xml", along with a style sheet that causes said
page to be rendered in a browser with subscribe links (pointing to
resource #1). The web UI tries to guide users to subscribe buttons first,
before showing them a raw feed URL.
Now this I can understand. Not too scary for users that don't have an
aggregator installed, but you still provide a clickable, subscribable link
for users that do.
Regards
James
