In fact, yes, this is true, but its easy to circumvent by using a bootstrap file. A simple application/xml MIME-type used against a standard non-web feed xml files ( e.g. http://mdavidpeterson.com/SessionConfig.aspx ) will allow you to then to circumvent the auto detection mechanism when you then call an atom feed from within the imported XSLT file. It seems to be this way, anway... is this, in fact the case? I guess thats more a question geared towards atom files that are served as application/atom+xml that are called internal to XSLT via the document function or external via _javascript_/XMLHTTP, etc... I am almost certain theres nothing that would connect the two processes (MSXML and the IEFrame.dll which seems to be the entry point for data feeds(yet another question I am unsure the answer to, but reading the registry seems to suggest this to be the case, and I'm not sure that gaining any sort of confirmation to this really matters all that much))
I guess some quick code would answer that question quite easily. I'll do just that and post the code and results to the UnderstandingAtom.com site for reference.
Thanks Sean!
I've been meaning to respond to this in the original thread (and to David Peterson's offline questions publicly), but got caught up in some other things.
There are a few principles we used to decide how to approach this problem (and it's not a straightforward issue with an easy decision matrix):
First, while the feed itself is data (as David points out ), the entries are the content from the publisher. The publisher has complete control over how each item in the feed looks (using (X)HTML). Entries can, of course, be re-mixed and shown in different contexts, losing their original feed context.
It is worth noting that no other aggregator maintains the publisher's look and feel on a feed. RSS Bandit and some others allow the user to control how a feed looks, and it requires custom, app-specific XSLs. If Safari has a way to turn off its feed view, I haven't found it yet.
To build on this idea, there is real value on a consistent view of feeds for the user, helping the user understand what they are looking at, and the context in which they can use the data. In fact, that's part of the promise of RSS – consistency.
For example, because the feed view is part of the client, instructions explaining what a feed is, and why subscribing is a useful and interesting thing to do are presented in the user's system language, regardless of the language of the feed. If the user chooses, they can turn off the IE feed view completely (starting from the next beta update).
Finally, we think that feeds+stylesheets exist as a stopgap measure to help users avoid the nasty XML view in browsers that don't support feeds (yes, this is a generalization, and some people are building web sites that are built in a more complicated way, but in the vast majority of cases, it's true). Now that the browsers support viewing feeds natively (this will be all major browsers, with the release of Firefox 2.0), this stop gap should be retired, or continue to exist only for older browsers.
There is a reasonable argument that this is a change in browser behaviour, and there's mention in another email that this is counter to the IE7 CSS promise of compatibility with sites.
The reality is that browsers have a nightmare process of dealing with millions of websites that have a near infinite set of permutations of how they use HTML. This is a side effect of the somewhat haphazard evolution of HTML in the 90s. I think it would be a complete mistake to repeat that here. The feed is nowhere near as large as the HTML community, and the opportunity exists to correct behaviour and do the right thing.
Yes, it's a change in browser behaviour, but that should not be the only argument. Since we are still at the cusp of the explosion of RSS/Atom into the mainstream, we should be deciding what is the right thing.
I argue that the right thing for a publisher is to serve HTML when they want control over the look and feel of the entire set of content, and to serve RSS/Atom when they want their data consumed as a feed (which has always meant surrendering the look-and-feel to the particular client the user chooses).
To address another implied point – we are not doing this out of some evil intent to screw the publisher or other clients. We have gone into this with the explicit intent of not only providing a decent feed reading experience in IE, but also to make sure that the entire community of aggregator and services is catered to – we have built and published extensive support for other aggregators and services to hook into the feed discovery experience and to synchronize with the Common Feed List that ships with IE. When a user subscribes to a feed using IE, he's not limited to using IE to read that feed. Any aggregator can build support for the publicly documented APIs to read and write to the Common Feed List, and any service can build support for synchronizing that feed with their service (and in both cases, several are doing so right now).
I hope this helps make the reasoning behind IE's behaviour with feeds and stylesheets a little less murky.
Thanks,
Sean
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Nesting
Sent: Thursday, March 09, 2006 7:30 AM
To: [EMAIL PROTECTED]
Cc: atom-syntax@imc.org
Subject: Re: IE7 Feed Rendering Issue
On 3/9/06, Klaus Johannes Rusch <[EMAIL PROTECTED] > wrote:
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.From the Mozilla/Firefox perspective, you may find these bugs interesting:
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
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
