Unless the "context" is stored with the feed, the user experience will
be different when a user follows a link from another page (rendered as
Web page) and later loads the same link again from the bookmarks
(rendered as an XML feed).
If this is just an issue with the example rules, that's solvable by adapting the rules to match expectations. Maybe browsers would be willing to store some sort of context along with the bookmark.
But really the underlying point is that browsers and/or feed readers can choose to render the feed however they want. The Atom syntax does not require xml-stylesheet support nor does any part of the Atom specification require that feed readers be web browsers, or that feeds be rendered as web pages.
It's important to remember here that we would be in exactly in the same position if any other non-Microsoft feed reading application registered itself as the handler for the application/xhtml+xml media type. IE and Firefox would dutifully pass the file to this 3rd-party application, which probably would not be a web browser, and the feed would be rendered in a reader-specific way, with zero attention paid to xml-stylesheet.
The behavior we're used to seeing is basically a fallback handler for arbitrary XML content. It's expected to be overridden when a real application steps up to say that it will handle content of that type. The IE feed reader case is somewhat distinct, but the implications are the same. The problem is that IE and Firefox's default behavior is actually useful, and a desirable alternative to applications legitimately stepping up to act as handlers for these media types.
If this is what we're trying to "fix", I think this is out of scope for this mailing list.
https://bugzilla.mozilla.org/show_bug.cgi?id=57342 - Add "View as Text/HTML/..." option for unknown mime content-type
https://bugzilla.mozilla.org/show_bug.cgi?id=194351 - General module to show widespread XML formats: WML, RSS, DocBook, OpenOffice.org etc.
The comments within the first bug also include discussion of overriding the web server's media type and/or the browser's behavior in response to it to permit content to be viewed using the browser's built-in text, HTML, or XML handling mechanisms. The discussion thus far seems to be just a variation of this, with a little automation (context) helping to make that decision.
David
