RE: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
This is fantastic, David. Many thanks. We're going over your feed in detail and I'll respond with bug information as soon as possible. Thanks, Sean -Original Message- From: David Powell [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 11:33 AM To: Sean Lyndersay Cc: atom-syntax@imc.org Subject: Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet) Hi Sean, I've been testing IE7 beta 2's support for Atom, with the following test feed: http://djpowell.net/atom-test/hardfeed/feed/hard-feed.atom Also here for easier viewing in IE7 http://djpowell.net/atom-test/hardfeed/feed/hard-feed.xml Here are the problems that I have found: 01. Person Extensions In Atom, extension elements can appear in feeds, entries, and person constructs. So atom:author and atom:contributor should preserve any extension elements. Currently, the transform only preserves atom:uri, atom:name, and atom:email. It should preserve all extensions too. 02. Timezones atom:updated is converted to RSS's RFC822 pubDate element, but the timezone information is lost. Eg: a date such as 2006-01-01T05:00:00+02:00 is converted to Sun, 01 Jan 2006 05:00:00 GMT, which is incorrect. 03. atom:published While atom:updated is converted to pubDate, atom:published is kept as atom:published; except, the date format is converted to RFC822 format. I think that the date format should be kept as-is in ISO8601-style format. 04. Alternate links for non-HTML types The entry called Binary Entry contains a link of the form: atom:link href=../files/bin.png length=684 type=image/png / This link isn't treated as the link for the entry, presumably because it has a type other than HTML. If no HTML link can be found for the alternate link, perhaps it would be worth just choosing any other alternate link instead. 05. HTML titles HTML in feed and entry titles is interpreted properly, but flattened to text. This is presumably deliberate but it does mean that there is some data loss. Perhaps the original atom namespaced element should be preserved as well in these cases? 06. atom:generator atom:generator is converted to RSS's generator. The uri attribute is included as an unnamespaced uri, but the version attribute is dropped. Perhaps both should be preserved, and it might be better to put the attributes into a namespace? 07. XHTML namespace prefix More of a rendering problem, but I've included it here because it is significant: xhtml content currently only works if the xhtml is in the default namespace. If a namespace prefix is used, it fails to be interpretted correctly. See the entry entitled: Entry with full iana [EMAIL PROTECTED] values; the link should appear as an HTML link, but doesn't. 08. IANA URIs for link relations A bit of a quirky one, but in Atom the rel values are actually URIs relative to http://www.iana.org/assignments/relation/, so rel=alternate and rel=http://www.iana.org/assignments/relation/alternate; should be treated the same. The same goes for enclosures. See the entry: Entry with full iana [EMAIL PROTECTED] values, which should show an enclosure and a valid entry link. 09. Category label atom:category is converted to RSS's category element. This causes the label attribute to be lost. It perhaps should be preserved as a namespaced attribute. Also, if it is available it might be better to use the label rather than the term as the RSS2 category name, because term might not be very human readable, that is the purpose of label. See Content Source Entry, which causes the WordNet URI to be displayed in the category filter box. 10. xml:base everywhere Some handling of xml:base is done if it appears on atom:feed or atom:entry, but it can appear anywhere. Eg, xml:base on the atom:link element should affect that link. There are a number of examples of xml:base being handled wrongly in the example, eg the broken feed logo. 11. xml:base / xml:lang namespace I notice that lang and base attributes appear on the transformed feed, but don't have the xml: namespace prefix? Is this a bug caused by the weirdness of the implicit xml: namespace? 12. Subscription name An IE7 bug, but I'll mention it here: If the feed title contains a line-break, the Subscribe to feed-dialog doesn't work because the line-break get's embedded as a hollow-square in the text box and causes an error. Try subscribing to the test feed, it works if you remove the hollow-box from the subscription name. 13. xml:base and xml:lang inheritance from atom:feed to entries xml:base and xml:lang at feed level should apply to all elements nested within the feed document. However the atom:feed element and its metadata can obviously change over time. This creates a problem: What if the atom:feed element contains an xml:base element, and it changes. The feed document as polled can be assumed to be consistent, but it would be wrong to retroactively apply this new base to old entries. In order to avoid these problems each
Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
Hi Sean, I've been testing IE7 beta 2's support for Atom, with the following test feed: http://djpowell.net/atom-test/hardfeed/feed/hard-feed.atom Also here for easier viewing in IE7 http://djpowell.net/atom-test/hardfeed/feed/hard-feed.xml Here are the problems that I have found: 01. Person Extensions In Atom, extension elements can appear in feeds, entries, and person constructs. So atom:author and atom:contributor should preserve any extension elements. Currently, the transform only preserves atom:uri, atom:name, and atom:email. It should preserve all extensions too. 02. Timezones atom:updated is converted to RSS's RFC822 pubDate element, but the timezone information is lost. Eg: a date such as 2006-01-01T05:00:00+02:00 is converted to Sun, 01 Jan 2006 05:00:00 GMT, which is incorrect. 03. atom:published While atom:updated is converted to pubDate, atom:published is kept as atom:published; except, the date format is converted to RFC822 format. I think that the date format should be kept as-is in ISO8601-style format. 04. Alternate links for non-HTML types The entry called Binary Entry contains a link of the form: atom:link href=../files/bin.png length=684 type=image/png / This link isn't treated as the link for the entry, presumably because it has a type other than HTML. If no HTML link can be found for the alternate link, perhaps it would be worth just choosing any other alternate link instead. 05. HTML titles HTML in feed and entry titles is interpreted properly, but flattened to text. This is presumably deliberate but it does mean that there is some data loss. Perhaps the original atom namespaced element should be preserved as well in these cases? 06. atom:generator atom:generator is converted to RSS's generator. The uri attribute is included as an unnamespaced uri, but the version attribute is dropped. Perhaps both should be preserved, and it might be better to put the attributes into a namespace? 07. XHTML namespace prefix More of a rendering problem, but I've included it here because it is significant: xhtml content currently only works if the xhtml is in the default namespace. If a namespace prefix is used, it fails to be interpretted correctly. See the entry entitled: Entry with full iana [EMAIL PROTECTED] values; the link should appear as an HTML link, but doesn't. 08. IANA URIs for link relations A bit of a quirky one, but in Atom the rel values are actually URIs relative to http://www.iana.org/assignments/relation/, so rel=alternate and rel=http://www.iana.org/assignments/relation/alternate; should be treated the same. The same goes for enclosures. See the entry: Entry with full iana [EMAIL PROTECTED] values, which should show an enclosure and a valid entry link. 09. Category label atom:category is converted to RSS's category element. This causes the label attribute to be lost. It perhaps should be preserved as a namespaced attribute. Also, if it is available it might be better to use the label rather than the term as the RSS2 category name, because term might not be very human readable, that is the purpose of label. See Content Source Entry, which causes the WordNet URI to be displayed in the category filter box. 10. xml:base everywhere Some handling of xml:base is done if it appears on atom:feed or atom:entry, but it can appear anywhere. Eg, xml:base on the atom:link element should affect that link. There are a number of examples of xml:base being handled wrongly in the example, eg the broken feed logo. 11. xml:base / xml:lang namespace I notice that lang and base attributes appear on the transformed feed, but don't have the xml: namespace prefix? Is this a bug caused by the weirdness of the implicit xml: namespace? 12. Subscription name An IE7 bug, but I'll mention it here: If the feed title contains a line-break, the Subscribe to feed-dialog doesn't work because the line-break get's embedded as a hollow-square in the text box and causes an error. Try subscribing to the test feed, it works if you remove the hollow-box from the subscription name. 13. xml:base and xml:lang inheritance from atom:feed to entries xml:base and xml:lang at feed level should apply to all elements nested within the feed document. However the atom:feed element and its metadata can obviously change over time. This creates a problem: What if the atom:feed element contains an xml:base element, and it changes. The feed document as polled can be assumed to be consistent, but it would be wrong to retroactively apply this new base to old entries. In order to avoid these problems each entry needs to store the xml:lang and xml:base context at the time it was last seen in the document. I think that if a document has xml:lang set on atom:feed, then this attribute should be written to all item elements, unless it is overridden on that atom:entry element. Same for xml:base, except you might need to resolve the entry base against the feed base. Actually if you
Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
David Powell wrote: 03. atom:published While atom:updated is converted to pubDate, atom:published is kept as atom:published; except, the date format is converted to RFC822 format. I think that the date format should be kept as-is in ISO8601-style format. Why is atom:updated converted to pubDate? If any atom date is converted to pubDate, why isn't it atom:published? - Sam Ruby
Re: Link rel attribute stylesheet
On Feb 26, 2006, at 9:10 PM, James Yenne 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? One problem with this is that there's no machine readable way without an extension attribute to indicate what format the stylesheet is going to transform the data to. If you're going to add an extension attribute, I'd suggest just making the whole thing an extension element instead. Of course, my opinion is partly based on my preference which was rejected by the group for limiting the link element to links intended for traversal, so maybe that doesn't matter. But certainly the possibility should be considered that this is stretching the use of the link element beyond what it was designed for. Antone
Re: Link rel attribute stylesheet
When you say what it was designed for can you be specific as to what that definition is? Sorry, new to the conversation, but I have particular interest in this topic as it is my belief that the URI/IRI can be used to imply a lot of information that is otherwise hidden from view, or uses more complex mechanisms to achieve the same result. If there is real concern as to this approach, it would be great to gain a greater understanding as what they are such that I can apply this to the work I am doing in this area. For a particular example of what I mean, please see this post http://www.xsltblog.com/archives/2006/02/what_rest_gets_1.html Thanks in advance! On 2/27/06, Antone Roundy [EMAIL PROTECTED] wrote: On Feb 26, 2006, at 9:10 PM, James Yenne 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? One problem with this is that there's no machine readable way withoutan extension attribute to indicate what format the stylesheet isgoing to transform the data to.If you're going to add an extensionattribute, I'd suggest just making the whole thing an extension element instead.Of course, my opinion is partly based on my preference which wasrejected by the group for limiting the link element to links intendedfor traversal, so maybe that doesn't matter.But certainly the possibility should be considered that this is stretching the use ofthe link element beyond what it was designed for.Antone-- M:D/M. David Peterson http://www.xsltblog.com/
RE: Link rel attribute stylesheet
I think what you're asking is, what's the resulting document's type or !DOCTYPE? In my case, the xsl supplied in the xml-stylesheet directive does the transformation and the resulting document is (strict) xhtml with the correct doctype. Perhaps the CSS2 media attribute, if added to Atom links would provide this cue about the format... E.g. media=print, handheld. Re an extension element, this all works (is valid) if the link rel is an IRI, so an extension is not needed. I was looking for other use cases for a stylesheet link rel., such as the feed entry case, to bolster a position to have stylesheet added to the List of Relations. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Antone Roundy Sent: Monday, February 27, 2006 7:05 AM To: atom-syntax@imc.org Subject: Re: Link rel attribute stylesheet On Feb 26, 2006, at 9:10 PM, James Yenne 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? One problem with this is that there's no machine readable way without an extension attribute to indicate what format the stylesheet is going to transform the data to. If you're going to add an extension attribute, I'd suggest just making the whole thing an extension element instead. Of course, my opinion is partly based on my preference which was rejected by the group for limiting the link element to links intended for traversal, so maybe that doesn't matter. But certainly the possibility should be considered that this is stretching the use of the link element beyond what it was designed for. Antone
Re: Link rel attribute stylesheet
James Yenne wrote: [snip] correct doctype. Perhaps the CSS2 media attribute, if added to Atom links would provide this cue about the format... E.g. media=print, handheld. Take a look at http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-02.txt It's completely experimental at this point, but does include a media attribute adapted from (x)html. - James
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 PetersonSent: Sunday, February 26, 2006 10:50 PMTo: James YenneCc: atom-syntax@imc.orgSubject: 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 recognizabledomainm 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. Soif 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: Datesare left in the atom ns, but arenot rendered as rfc3339, but rather converted to rfc822; an email address is not included in the RSS2 managing editor as required, butexists in the Atom feed author/email,and more. line 2, column 252: managingEditor must include an email address [ help] ... GMT/pubDatemanagingEditorShop/managingEditoratom:authora ...^ line 2, column 269: Undefined channel element: atom:author [ help] ... nagingEditorShop/managingEditoratom:authoratom:nameSh ...^ line 2, column 370: Undefined channel element: guid [ help] ... [EMAIL PROTECTED]/atom:email/atom:authorguid 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/
Re: Link rel attribute stylesheet
On Feb 27, 2006, at 8:29 AM, M. David Peterson wrote: When you say what it was designed for can you be specific as to what that definition is? Well, we failed to gain consensus on that. Some of us wanted it to be used only for links intended to be traversed by the user (like the a element in HTML with an href attribute--the link is there so that the user can click it and get to the linked resource). Others didn't want this limitation, but wanted the link to be resolvable (eg., no tag: URIs). Others wanted to be able to stick any URI in it. So there is no tightly defined what it was designed for. I'm just saying that if an extra attribute is required to disambiguate what's being pointed to in a case like the following (without requiring the link target to be loaded and inspected), then maybe you're trying to make this one element do too much: link rel=stylesheet href=http://example.org/atom-2-rss-2.0.xsl; / link rel=stylesheet href=http://example.org/atom-2-rss-1.0.xsl; / link rel=stylesheet href=http://example.org/atom-2-fooml.xsl; / etc. If one were to encounter such a list of links at the top of an Atom document, which should one use? Should one download all of them and then pick one? Or are you going to add an attribute something like this: link rel=stylesheet href=http://example.org/atom-2-rss-2.0.xsl; ext:targettype=application/xml+rss / Sorry, new to the conversation, but I have particular interest in this topic as it is my belief that the URI/IRI can be used to imply a lot of information that is otherwise hidden from view, or uses more complex mechanisms to achieve the same result. If there is real concern as to this approach, it would be great to gain a greater understanding as what they are such that I can apply this to the work I am doing in this area. For a particular example of what I mean, please see this post http://www.xsltblog.com/archives/2006/02/what_rest_gets_1.html Hmm. If I'm reading that right, I wouldn't want to organize my websites that way. And unless the specification for the stylesheet link relation were to mandate that URIs be constructed in a way enables readers to tell from the local path what type the stylesheet is going to transform the feed to, you wouldn't have any way to know whether you could apply such an interpretation in any given case. I don't really see the benefit of putting the information into the URI versus creating an attribute whose sole purpose is to specify the type. The number of bits it would save is trivial, and it would require the extra step of parsing the URI's local path to pull information out of it that could be taken more easily from a dedicated attribute. Antone
Re: Link rel attribute stylesheet
On 2/27/06, Antone Roundy [EMAIL PROTECTED] wrote: Hmm.If I'm reading that right, I wouldn't want to organize mywebsites that way. Nor would I. I wouldn't advocate and actual directory structure as this, and instead a simple disection of the URI/IRI that would then be mapped to the proper Class/Method. In fact, in many cases you would simply be using this as a way to logically gain access to a returned set of XML for processing on the client. With this in mind, this could also, and more instinctively represent a specified XPath that simple used the preceding verb to determine the format of the returned XML ( e.g. embedding a sequenced set of instruction elementsinto the return XML expressing to the client what it would need to do to properly take the contained data set, process it, to then pass this to the proper process on the client for display, or for further processing. With this in mind, then yeah, youre right... the attributes could provide quite a bit of extended value that would never require a need to be sent to the server as the result wouldrequire the server to send the same attributes and values back to the client. Unless that information is required to insure that theinfoset returned contains the correct data in which could only be determined by such attributes, then you're right... no need to send it for the sake of sending it. And unless the specification for the stylesheetlink relation were to mandate that URIs be constructed in a way enables readers to tell from the local path what type the stylesheetis going to transform the feed to, you wouldn't have any way to knowwhether you could apply such an interpretation in any given case. Again, I agree, although with reservations. For those times in which an XML file is requested directly from the address bar of a browser such as to cause a refresh of the browsers state upon its return, then embedding the neccessarytransformation file as a PIin the return XMLinfoset would allow this data to properly instantiate a transformation process. Of course, in cases such as this we've now abandoned our original Atom data feed for something completely different which means: - We're well of topic - This would be the improper list to discuss such situations. Idon't really see the benefit of putting the information into the URIversus creating an attribute whose sole purpose is to specify the type.The number of bits it would save is trivial, and it wouldrequire the extra step of parsing the URI's local path to pullinformation out of it that could be taken more easily from adedicated attribute. If this were to be the only point, then you're right... it would be pointless. But, at least the way I am currently thinking about using this scenario,the information contained in the URI/IRI is not to determine type, and instead to instantiate a process on the server that relates directly to the desired action for the server to take using the/verb/noun format, and as such return a specific set of instruction elements expressing a detailed list of instructions that the client should then perform to complete the requested task. While there are plenty more reasonsthan just this, one of primary benefits of using a system like this is that it brings into the equation the notion that the client would need to know very little to invoke a fairly complicated process. So, in essence, using the URI/IRI we could exprress to the server that we would like to send a message to a particular department or person within a company, and the result would not only contain a form to put your message into, but also the necessary information on how to go about sending this message (the proper URI/IRI, the proper format, etc...) as well as potentially a session-id-like key that would only allow for that unique ID to carry out a posted set of information to that particular person, and allow this to happen only one time. A new message would require a new request to the same URI/IRI. A system like this would easily allow for basic logic to be built in suggesting that any two requests from the same client in a specific period of time would be denied, the result bringing a stronger shield against spammers and the like. Ultimatelly, (bringing this back to Atom) this type of URI/IRI usage could be coupled with subscribable programmability, in which our existing world of browsers would be enabled to perform a greater set of fairly complex tasks, the inititial client session could remain fairly thin, thus keeping things both fast and effiicient, would reduce server-load to simply return XML infosets in which no other information other than the URI/IRI would be required, therefore reducing server side CPU-cylces, and all of this could take place in a decentralized, subscription based world (via Atom data feeds, of course) which would mean that the software would ALWAYS be up-to-date (to ensure built in browser security measures are properly handled, the server would be required to keep the
Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
Sean Lyndersay wrote: 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). Re the flagging of atom: elements: this was indeed a bug in the Feed Validator. The Feed Validator was incorrectly flagging the use of atom:author elements at the channel level and atom:link elements at the item level. A test case has been expanded to include these elements, and these problems have been corrected. The fix should be deployed online in a matter of hours. - Sam Ruby
Re: Link rel attribute stylesheet
I've been experimenting with the use of rel=stylesheet to provide a relatively safe way of attaching styles to syndicated content. The dangers of allowing embedded styles in syndicated content are well known [1], however, it still makes sense to provide an optional way of allowing publishers and consumers to attach style to content. entry ... link rel=stylesheet type=text/css href=hcard.css / content type=xhtml div xmlns=... class=vCard a class=url fn href=...John Doe/a div class=orgFoo, Inc./div /div /content /entry entry ... link rel=stylesheet type=application/xslt+xml href=... / content type=application/xml a xmlns=urn:foo b cfoo/c dbar/d /b /a /content /entry Consumers could choose to apply or ignore the style... preferably based on user choice. [1]http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely James Yenne 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
Re: Link rel attribute stylesheet
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 havehad on my listto 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="" href="http://www.xsltblog.com/feed.atom">http://www.xsltblog.com/feed.atom / link rel=alternate type=application/xml title=XSLT:Blog/[EMAIL PROTECTED] = 'Atom']/@dataFeed href="" href="http://www.xsltblog.com/atom.xml">http://www.xsltblog.com/atom.xml /link rel=alternate type=application/rdf+xml title=XSLT:Blog/[EMAIL PROTECTED] = 'RSS+RDF']/@dataFeed href="" href="http://www.xsltblog.com/index.rdf">http://www.xsltblog.com/index.rdf /link rel=alternate type=application/xml title=XSLT:Blog/[EMAIL PROTECTED] = 'RSS 2.0']/@dataFeed href="" href="http://www.xsltblog.com/index.xml">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 . Thishappens for the same reason as above: application/atom+xmland application/rss+xmlMIME-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 thatAtom 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?) Alink 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 Petersonhttp://www.xsltblog.com/
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 havehad on my listto 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="" 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="" 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="" 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="" 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 . Thishappens for the same reason as above: application/atom+xmland application/rss+xmlMIME-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 thatAtom 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?) Alink 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 Petersonhttp://www.xsltblog.com/
RE: Link rel attribute stylesheet
Yes, I currently work around using the IRI, as mentioned, to specify the relationship and that works fine. Re namesapces, I just think namespaces are plentiful already and add a little more work in terms of parsing. I'm applying them at the feed level, and as James Snell shows, they can be useful in entries also. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis Sent: Sunday, February 26, 2006 8:43 PM To: atom-syntax@imc.org Subject: Re: Link rel attribute stylesheet * James Yenne [EMAIL PROTECTED] [2006-02-27 05:25]: 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. Smells like abuse to me. Id pass it to the XSL transform using a namespaced element instead, à la feed xmlns=http://www.w3.org/2005/Atom; css xmlns=tag:example.org,2006:Foo/somewhere/over/the/rainbow.css/css !-- ... -- /feed If you really dont want to put in a namespaced element for some (odd?) reason, you can use an IRI to specify the relationship: atom:link rel=http://example.org/rel/stylesheet; href=/somewhere/over/the/rainbow.css/ I dont think a `stylesheet` relationship warrants adoption in the canon in any case. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Link rel attribute stylesheet
* James Yenne [EMAIL PROTECTED] [2006-02-27 07:20]: as James Snell shows, they can be useful in entries also. Yeah, I hadn’t thought about it in terms of styling content in standalone aggregators, only as a hatch for XSL transforms applied for friendlier in-browser presentation. For the latter, I still think using `atom:link` is abuse, but I agree that the former is a worthwhile use case so at this point I’m +0 to this. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: Link rel attribute stylesheet
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.Soif 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:Datesare left in the atom ns, but arenot rendered as rfc3339, but rather converted to rfc822; an email address is not included in theRSS2 managing editor as required, butexists in the Atom feed author/email,and more. line 2, column 252: managingEditor must include an email address [help] ... GMT/pubDatemanagingEditorShop/managingEditoratom:authora ...^ line 2, column 269: Undefined channel element: atom:author [help] ... nagingEditorShop/managingEditoratom:authoratom:nameSh ...^ line 2, column 370: Undefined channel element: guid [help] ... [EMAIL PROTECTED]/atom:email/atom:authorguid 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:publishedauthorS ...^ line 8, column 216: author must include an email address (3 occurrences) [help] ... 4 GMT/atom:publishedauthorShop/authoratom:author xmlns:atom ...^ line 8, column 445: Undefined item element: atom:link (6 occurrences) [help] ... 904ca-3e80-4c74-8a62-926fa83405ac/guidatom: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;/divgt;/descriptioncf:id2/cf:idcf:readtrue/cf:read/item/ ...^ line 19, column 74: Missing channel element: link [help] lt;/divgt;/descriptioncf:id2/cf:idcf:readtrue/cf:read/item/ ... From: M. David Peterson [mailto:[EMAIL PROTECTED] Sent: Sunday, February 26, 2006 8:53 PMTo: James YenneCc: atom-syntax@imc.orgSubject: 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 havehad on my listto 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="&
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 recognizabledomainm 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. Soif 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: Datesare left in the atom ns, but arenot rendered as rfc3339, but rather converted to rfc822; an email address is not included in the RSS2 managing editor as required, butexists in the Atom feed author/email,and more. line 2, column 252: managingEditor must include an email address [ help] ... GMT/pubDatemanagingEditorShop/managingEditoratom:authora ...^ line 2, column 269: Undefined channel element: atom:author [ help] ... nagingEditorShop/managingEditoratom:authoratom:nameSh ...^ line 2, column 370: Undefined channel element: guid [ help] ... [EMAIL PROTECTED]/atom:email/atom:authorguid isPermaLink=falseurn: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/AtomSun, 26 Feb 2006 14:35:04 GMT/atom:publishedauthorS ...^ line 8, column 216: author must include an email address (3 occurrences) [ help] ... 4 GMT/atom:publishedauthorShop/authoratom:author xmlns:atom ...^ line 8, column 445: Undefined item element: atom:link (6 occurrences) [ help] ... 904ca-3e80-4c74-8a62-926fa83405ac/guidatom: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=htmllt;div ...^ line 19, column 74: Missing channel element: description [ help] lt;/divgt;/descriptioncf:id2/cf:idcf:readtrue/cf:read/item/ ... ^ line 19, column 74: Missing channel element: link [help ] lt;/divgt;/descriptioncf:id2/cf:idcf:readtrue/cf:read/item/ ... From: M. David Peterson [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 26, 2006 8:53 PM To: James YenneCc: atom-syntax@imc.orgSubject: 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
