RE: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")

Sean Lyndersay Mon, 27 Feb 2006 12:39:10 -0800

Thanks James. I’ve filed bugs in our bug tracking database for each of the issues that came up in the feed validator (except for flagging atom:* items, since these are a correct use of RSS 2.0 extension namespaces).

Sean

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Yenne
Sent: Monday, February 27, 2006 9:37 AM
To: 'M. David Peterson'
Cc: [email protected]
Subject: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")

For anyone interested, I created a validated Atom feed that (http://softwareme.com/ie7test.xml) exhibits the problems with IE's refactor as RSS2. After hitting the IE7 Subscribe button, the feed is then converted to RSS2 (http://softwareme.com/ie7testsubscribed.xml), which doesn't validate (http://feedvalidator.org/check.cgi?url="">) although still works in IE.

I would imagine this is important when you start using the MS API and figure out things are wrong or missing, e.g. atom:published in rfc822 format, etc.

The other problem seems to be that IE7 doesn't allow or use in the same way the xml-stylesheet directive - its stripped off. FF1.5 and IE6 render using the supplied xml-stylesheet directive, as can be seen using http://www.atomenabled.org/atom.xml

Note: This test feed does not include the xsl/css solution I'm using.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. David Peterson
Sent: Sunday, February 26, 2006 10:50 PM
To: James Yenne
Cc: [email protected]
Subject: Re: Link rel attribute "stylesheet"

If you quickly check the list archives you will notice that this very conversation is taking place directly with members of the IE7/RSS team. The short of it is that that MS is taking the RSS '2.0' format and extending it in areas necessary to allow for what will eventually be a 1:1 mapping, without data corruption or fidelity loss. I've written a follow-up piece to this conversation directed towards the IE7/RSS folks, of which you can find here > http://www.xsltblog.com/archives/2006/02/this_is_a_call.html < While the post I think brings out some important points, recent comments led to what I believe is a bit more interesting in regards to the mindset of a lot of folks in that they simply do not understand what the inherent issues with RSS ' 2.0' are and how and why the Atom specification fixes these problems. If there was ever a more crucial moment in time to bring these points into an easily accessible and recognizable domainm which provided a consolidated, well linked, and well documented summary of the available content, now would be that time.

In fact, after recording with Kurt (Cagle) our next podcast tonight, I will be finishing off a wiki in which anyone can then easily access and update as they see fit, with this exact purpose in mind. Using a domain that I think fits quite well into this general topic, it will be found at http://www.understandingatom.com/ when complete. When all is said and done I then plan to create a blog post to on my O'Reilly blog such that the process of evangelizing this can be made known to the broad, XML.com/OReillynet audience.

I'll ping back this list when its ready.

re: your XSLT PI problem with IE7. Is the code live somewhere that is accessible such that I can take a look at it and help you debug the problem?

On 2/26/06, James Yenne <[EMAIL PROTECTED]> wrote:

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.

· line 2, column 252: managingEditor must include an email address [ help]

...  GMT</pubDate><managingEditor>Shop</managingEditor><atom:author><a ...

                                             ^


·  line 2, column 269: Undefined channel element: atom:author
[ help]

... nagingEditor>Shop</managingEditor><atom:author><atom:name>Sh ...

                                             ^

·  line 2, column 370: Undefined channel element: guid [ help]

... [EMAIL PROTECTED]</atom:email></atom:author><guid isPermaLink="false">urn:gu ...


                                             ^

·  line 2, column 643: Unexpected uri attribute on generator
element [ help]

... .css" rel="stylesheet" type="text/css"/><generator uri="urn:activera-com ...

                                             ^

·  line 8, column 181: atom:published must be an RFC-3339
date-time (3 occurrences) [ help]

... 2005/Atom">Sun, 26 Feb 2006 14:35:04 GMT</atom:published><author>S ...

                                             ^

·  line 8, column 216: author must include an email address (3
occurrences) [ help]

... 4 GMT</atom:published><author>Shop</author><atom:author xmlns:atom ...

                                             ^

·  line 8, column 445: Undefined item element: atom:link (6
occurrences) [ help]

... 904ca-3e80-4c74-8a62-926fa83405ac</guid><atom:link xmlns:atom="http://ww ...

                                             
^

·  line 8, column 854: Unexpected type attribute on
description element (3 occurrences) [ help]

... ype="application/xml" title="Location"/><description type="html">&lt;div ...

                                             ^

·  line 19, column 74: Missing channel element: description [ help]

    &lt;/div&gt;</description><cf:id>2</cf:id><cf:read>true</cf:read></item></ ...

                                                                          
^

·  line 19, column 74: Missing channel element: link [help ]

    &lt;/div&gt;</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: [email protected]
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:

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/

RE: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")

Reply via email to