I'm "pre-caching" feeds as xml files and have not added
this mime type to the server, so no, they're served as text/xml. IE7
appears to recognize them as feeds because you can see it does its re-factor of
the Atom feed as RSS2. Why does IE7 convert Atom feeds to RSS2 and use the
Atom ns in the RSS2 feed?. I seem to have lost control of how my feed is
rendered in IE7. I can render per my own XSL in IE6 and FF1.5. Are
you saying that using application/atom+xml cause IE7 to keep the
xsl?
The links in the generated RSS2 are broken: when I mouse over links, it
doesn't include anything after the domain (.com) in the url. So if an
entry link href contains search parameters, it's chopped off. Inspecting the raw xml, however, the search
parameters are still present, so IE seems to have a
bug.
The IE7 conversion from Atom to RSS2 also doesn't pass the
feed validators... here's an example validated Atom feed, and the IE7 RSS2
conversion creates a channel that does not validate:
Dates are
left in the atom ns, but
are not rendered as rfc3339,
but rather converted to rfc822; an email
address is not included in the RSS2
managing editor as required, but exists in the Atom feed author/email, and more.... GMT</pubDate><managingEditor>Shop</managingEditor><atom:author><a ...
^
... nagingEditor>Shop</managingEditor><atom:author><atom:name>Sh ...
^
... [EMAIL PROTECTED]</atom:email></atom:author><guid isPermaLink="false">urn:gu ...
^
... .css" rel="stylesheet" type="text/css"/><generator uri="urn:activera-com ...
^
line 8, column 181: (3 occurrences) [help]
... 2005/Atom">Sun, 26 Feb 2006 14:35:04 GMT</atom:published><author>S ...
^
line 8, column 216: (3 occurrences) [help]
... 4 GMT</atom:published><author>Shop</author><atom:author xmlns:atom ...
^
line 8, column 445: (6 occurrences) [help]
... 904ca-3e80-4c74-8a62-926fa83405ac</guid><atom:link xmlns:atom="http://ww ...
^
line 8, column 854: (3 occurrences) [help]
... ype="application/xml" title="Location"/><description type="html"><div ...
^
</div></description><cf:id>2</cf:id><cf:read>true</cf:read></item></ ...
^
</div></description><cf:id>2</cf:id><cf:read>true</cf:read></item></ ...
From: M. David Peterson [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 26, 2006 8:53 PM
To: James Yenne
Cc: atom-syntax@imc.org
Subject: Re: Link rel attribute "stylesheet"
correction:
serving the .xml extension as with an application/xml extension
should read: serving the .xml extension as with an application/xml MIME-type (bunch of other spelling and grammar errors, but I would rather not waste everyones time showcasing something most already know... a first take at most anything I write tends to send the spell checking engine into fits of fury... so I save my CPU cycles for take two and beyond :)
On 2/26/06, M. David
Peterson <[EMAIL PROTECTED]> wrote:
Neat idea :)> Why does IE7 rip out xml-stylesheet directives.I can only assume your server is serving up the atom file (correctly) as application/atom+xml? If yes, application/atom+xml is transfered directly to the feed rendering mechanism, bypassing the xml parsing mechanism that would read the processing instruction for the transformation file, access this file, to then render accordingly. This is one of those situations I have had on my list to bring up to this group, and now that my time has freed up quite a bit from other projects, coupled with your post, now seems as good a time as any to start gaining some greater insite from the list members as to what the proper way to handle this situation is.I don't want to propogate this particular solution until I can say for sure that, in fact, it is the correct solution, but the simplest way I have found that seems to make the most sense is to create two atom feeds, one with an .xml extension, and one with an .atom extension, serving the .xml extension as with an application/xml extension, and the .atom as application/atom+xml.As a related side note: One of benefits I have discovered with IE7's general approach to data feeds comes within the context of autodiscovery. Here's what the link elements look like in the head of my personal blog:<link rel="alternate" type="application/atom+xml" title="XSLT:Blog/Main/@dataFeed" href=""http://www.xsltblog.com/feed.atom" target=_blank> http://www.xsltblog.com/feed.atom" />
<link rel="alternate" type="application/xml" title="XSLT:Blog/[EMAIL PROTECTED] = 'Atom']/@dataFeed" href=""http://www.xsltblog.com/atom.xml" target=_blank> http://www.xsltblog.com/atom.xml " />
<link rel="alternate" type="application/rdf+xml" title="XSLT:Blog/[EMAIL PROTECTED] = 'RSS+RDF']/@dataFeed" href=""http://www.xsltblog.com/index.rdf" target=_blank> http://www.xsltblog.com/index.rdf " />
<link rel="alternate" type="application/xml" title="XSLT:Blog/[EMAIL PROTECTED] = 'RSS 2.0']/@dataFeed" href=""http://www.xsltblog.com/index.xml" target=_blank> http://www.xsltblog.com/index.xml " />If you visit http://www.xsltblog.com in IE7 you will notice that when you select the datafeed notification dropdown, it only shows the first entry above, titled " XSLT:Blog/Main/@dataFeed ". This happens for the same reason as above: application/atom+xml and application/rss+xml MIME-types invoked the feed rendering engine, and the same is true for autodiscovery links in the context of what IE7 will list as a data feed and what it will not. Of course, a simple way to ensure that folks using IE7 are only shown the data feed formats you would prefer for them to show is by setting the @type value of the non-prefered link elements to application/xml, which is perfectly legal, and as such doesn't break anything else that might not use the same type restraints.Of course, I'm not advocating this as something that should be implemented such that your visitors are forced into some sort of proprietary type thing... But give the fact that Atom is a specification backed by both IETF as well as the W3C, it seems to me that the only way to ensure that your site visitors will not have to make changes and updates to their data feed subscriptions is to focus on those that have gone through the full standardization process, and as such companys like MS can build solutions that they know are going to be compliant in 6 month, 6 years, and beyond. Thats both reassuring to them AND most importantly, your site visitors.
--On 2/26/06, James Yenne <[EMAIL PROTECTED] > wrote:My feeds contain a generic xml-stylesheet, which formats the feed for display along with a feed-specific css. Since xsl processors do not have a standard way to pass parameters to xsl stylesheets, I provide this feed-specific css to the xsl processor in the feed as a link with rel="stylesheet". Generating xhtml with this xsl/css solution works for rendering both in IE6 and FF1.5. (Why does IE7 rip out xml-stylesheet directives?)A link rel="stylesheet" seems to be the most efficient solution, however, a fully qualified URI relation does the job too. I would like to request a stylesheet link relation be added to the IANA List of Relations and supported in the validators. Thoughts?Thanks,James
<M:D/>
M. David Peterson
http://www.xsltblog.com/
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
