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: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")
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: atom-syntax@imc.org 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: atom-syntax@imc.org 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] ... GMTShop ^ · line 2, column 269: Undefined channel element: atom:author [ help] ... nagingEditor>ShopSh ... ^ ·
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 elements into 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 would require the server to send the same attributes and values back to the client. Unless that information is required to insure that the infoset 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 "stylesheet"link 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 know whether 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 neccessary transformation file as a PI in the return XML infoset 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 reasons than 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 s
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 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: http://example.org/atom-2-rss-2.0.xsl"; /> http://example.org/atom-2-rss-1.0.xsl"; /> 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: 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
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 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] ... GMTShop ^ line 2, column 269: Undefined channel element: atom:author [ help] ... nagingEditor>ShopSh ... ^ line 2, column 370: Undefined channel element: guid [ help] ... [EMAIL PROTECTED]urn:gu ... ^ line 2, column 643: Unexpected uri attribute on generator element [ help] ... .css" rel="stylesheet" type="text/css"/>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 GMTS ...
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
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"
To be a bit more specific to your point: One problem with this is that there's no machine readable way withoutan extension attribute to indicate what format the stylesheet is going to transform the data to. It seems to me that this could potentially be handled quite easily with the URI/IRI and not require the need for an extension attribute. But I will leave plenty of room for the notion that there could be several missing pieces that I do not presently have that could make this unusable in regards to a potential solution. At this stage I'm really just trying to gather information such that I can try and prove every reason why this might not work such that if I can't, it will go quite a bit further th to say "I have tried to break this using this, this, and this" than it would to say "I can't think of any reasons this wouldn't work, so lets do it and take a whole bunch of risk because of it" On 2/27/06, M. David Peterson <[EMAIL PROTECTED]> wrote: 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. David Peterson http://www.xsltblog.com/ -- M. David Petersonhttp://www.xsltblog.com/
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. David Peterson http://www.xsltblog.com/
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
