Subject: Link rel attribute "stylesheet"

From: "James Yenne" <[email-masked]>
Date: Sun, 26 Feb 2006 20:10:57 -0800

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

---

From: James M Snell <[email-masked]>
Date: Sun, 26 Feb 2006 20:37:41 -0800

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="org">Foo, Inc.</div>
    </div>
  </content>
</entry>

<entry>
  ...
  <link rel="stylesheet" type="application/xslt+xml" href="..." />
  <content type="application/xml">
    <a xmlns="urn:foo">
      <b>
        <c>foo</c>
        <d>bar</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:
> 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
> 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

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 27 Feb 2006 05:42:56 +0100

* James Yenne <[email-masked]> [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. I’d 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 don’t 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 don’t think a `stylesheet` relationship warrants adoption in
the canon in any case.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "M. David Peterson" <[email-masked]>
Date: Sun, 26 Feb 2006 21:46:31 -0700

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" />
<link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format =
'Atom']/@dataFeed" href="http://www.xsltblog.com/atom.xml" />
<link rel="alternate" type="application/rdf+xml"
title="XSLT:Blog/Main[@format = 'RSS+RDF']/@dataFeed" href="
http://www.xsltblog.com/index.rdf" />
<link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format =
'RSS 2.0']/@dataFeed" href="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-masked]> wrote:
> 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
> 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

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Sun, 26 Feb 2006 21:53:24 -0700

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-masked]> wrote:
> 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/xml" title="XSLT:Blog/Main[@format
> = 'Atom']/@dataFeed" href="http://www.xsltblog.com/atom.xml " />
> title="XSLT:Blog/Main[@format = 'RSS+RDF']/@dataFeed" href="http://www.xsltblog.com/index.rdf
> " />
> <link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format
> = 'RSS 2.0']/@dataFeed" href="http://www.xsltblog.com/index.xml " />
>
> 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.
>
> > have a standard way to pass parameters to xsl stylesheets, I provide this
> > 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/

---

From: "James Yenne" <[email-masked]>
Date: Sun, 26 Feb 2006 22:05:46 -0800

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-masked] [mailto:[email-masked]]
On Behalf Of A. Pagaltzis
Sent: Sunday, February 26, 2006 8:43 PM
To: [email-masked]
Subject: Re: Link rel attribute "stylesheet"

* James Yenne <[email-masked]> [2006-02-27 05:25]:
>rel="stylesheet".

Smells like abuse to me. I’d 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>

    <atom:link rel="http://example.org/rel/stylesheet"
href="/somewhere/over/the/rainbow.css"/>

I don’t think a `stylesheet` relationship warrants adoption in the canon in
any case.

Regards,

---

From: "'A. Pagaltzis'" <[email-masked]>
Date: Mon, 27 Feb 2006 07:25:13 +0100

* James Yenne <[email-masked]> [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,

---

From: "James Yenne" <[email-masked]>
Date: Sun, 26 Feb 2006 22:28:47 -0800

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
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> 2, column 252: managingEditor
must include an email address [help
<http://feedvalidator.org/docs/error/InvalidContact.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> 2, column 269: Undefined
channel element: atom:author [help
<http://feedvalidator.org/docs/error/UndefinedElement.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> 2, column 370: Undefined
channel element: guid [help
<http://feedvalidator.org/docs/error/UndefinedElement.html> ]

... [email-masked]</atom:email></atom:author><guid isPermaLink="false">urn:gu
...
                                             ^

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> 2, column 643: Unexpected uri
attribute on generator element [help
<http://feedvalidator.org/docs/error/UnexpectedAttribute.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> 8, column 181: atom:published
must be an RFC-3339 date-time (3 occurrences) [help
<http://feedvalidator.org/docs/error/InvalidRFC3339Date.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> 8, column 216: author must
include an email address (3 occurrences) [help
<http://feedvalidator.org/docs/error/InvalidContact.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> 8, column 445: Undefined item
element: atom:link (6 occurrences) [help
<http://feedvalidator.org/docs/error/UndefinedElement.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> 8, column 854: Unexpected type
attribute on description element (3 occurrences) [help
<http://feedvalidator.org/docs/error/UnexpectedAttribute.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19> 19, column 74: Missing
channel element: description [help
<http://feedvalidator.org/docs/error/MissingDescription.html> ]

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

*	
line
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19> 19, column 74: Missing
channel element: link [help
<http://feedvalidator.org/docs/error/MissingLink.html> ]

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

  _____  

From: M. David Peterson [mailto:[email-masked]] 
Sent: Sunday, February 26, 2006 8:53 PM
To: James Yenne
Cc: [email-masked]
Subject: Re: Link rel attribute "stylesheet"

correction:

 

Neat idea :)

 
<link rel="alternate" type="application/atom+xml"
title="XSLT:Blog/Main/@dataFeed" href="  <http://www.xsltblog.com/feed.atom>
http://www.xsltblog.com/feed.atom" /> 
<link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format =
'Atom']/@dataFeed" href="  <http://www.xsltblog.com/atom.xml>
http://www.xsltblog.com/atom.xml " />
<link rel="alternate" type="application/rdf+xml"
title="XSLT:Blog/Main[@format = 'RSS+RDF']/@dataFeed" href="
<http://www.xsltblog.com/index.rdf> http://www.xsltblog.com/index.rdf " />
<link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format =
'RSS 2.0']/@dataFeed" href="  <http://www.xsltblog.com/index.xml>
http://www.xsltblog.com/index.xml " />
 
If you visit http://www.xsltblog.com <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. 

On 2/26/06, James Yenne <[email-masked]
<mailto:[email-masked]> > wrote: 

 
Thanks,

James 

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/  <http://www.xsltblog.com/> 

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Sun, 26 Feb 2006 23:49:40 -0700

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-masked]> wrote:
> 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.
>
> line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 252: managingEditor must include an email address [help<http://feedvalidator.org/docs/error/InvalidContact.html>
> ]
>
>  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 269: Undefined channel element: atom:author [help<http://feedvalidator.org/docs/error/UndefinedElement.html>
> ]
>
>  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 370: Undefined channel element: guid [help<http://feedvalidator.org/docs/error/UndefinedElement.html>
> ]
>
> ... [email-masked]</atom:email></atom:author><guid isPermaLink="false">urn:gu ...
>                                              ^
>
>  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 643: Unexpected uri attribute on generator element [help<http://feedvalidator.org/docs/error/UnexpectedAttribute.html>
> ]
>
> ... .css" rel="stylesheet" type="text/css"/><generator uri="urn:activera-com ...
>                                              ^
>
>  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 181: atom:published must be an RFC-3339 date-time (3 occurrences) [
> help <http://feedvalidator.org/docs/error/InvalidRFC3339Date.html>]
>
>  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 216: author must include an email address (3 occurrences) [help<http://feedvalidator.org/docs/error/InvalidContact.html>
> ]
>
>  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 445: Undefined item element: atom:link (6 occurrences) [help<http://feedvalidator.org/docs/error/UndefinedElement.html>
> ]
>
> ... 904ca-3e80-4c74-8a62-926fa83405ac</guid><atom:link xmlns:atom="http://ww ...
>                                              ^
>
>  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 854: Unexpected type attribute on description element (3
> occurrences) [help<http://feedvalidator.org/docs/error/UnexpectedAttribute.html>
> ]
>
> ... ype="application/xml" title="Location"/><description type="html">&lt;div ...
>                                              ^
>
>  line 19<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19>,
> column 74: Missing channel element: description [help<http://feedvalidator.org/docs/error/MissingDescription.html>
> ]
>
> 		&lt;/div&gt;</description><cf:id>2</cf:id><cf:read>true</cf:read></item></ ...
>                                                                           ^
>
>  line 19<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19>,
> column 74: Missing channel element: link [help<http://feedvalidator.org/docs/error/MissingLink.html>
> ]
>
> 		&lt;/div&gt;</description><cf:id>2</cf:id><cf:read>true</cf:read></item></ ...
>
>
>
>  ------------------------------
> *From:* M. David Peterson [mailto:[email-masked]]
> *Sent:* Sunday, February 26, 2006 8:53 PM
> *To:* James Yenne
> *Cc:* [email-masked]
> *Subject:* Re: Link rel attribute "stylesheet"
>
>
>  correction:
>
>
> 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 :)
>
>
>
> > XSLT:Blog/Main/@dataFeed" href=" http://www.xsltblog.com/feed.atom" />
> > <link rel="alternate" type="application/xml"
> > title="XSLT:Blog/Main[@format = 'Atom']/@dataFeed" href="http://www.xsltblog.com/atom.xml" />
> > title="XSLT:Blog/Main[@format = 'RSS+RDF']/@dataFeed" href="http://www.xsltblog.com/index.rdf "
> > />
> > <link rel="alternate" type="application/xml"
> > title="XSLT:Blog/Main[@format = 'RSS 2.0']/@dataFeed" href="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
> > 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
> >  On 2/26/06, James Yenne <[email-masked] > wrote:
> > >
> > > 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

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Antone Roundy <[email-masked]>
Date: Mon, 27 Feb 2006 08:05:29 -0700

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?)
>
> 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

---

From: "M. David Peterson" <[email-masked]>
Date: Mon, 27 Feb 2006 08:29:53 -0700

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!

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Mon, 27 Feb 2006 08:37:42 -0700

To be a bit more specific to your point:

> 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-masked]> 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

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "James Yenne" <[email-masked]>
Date: Mon, 27 Feb 2006 08:03:39 -0800

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-masked] [mailto:[email-masked]]
On Behalf Of Antone Roundy
Sent: Monday, February 27, 2006 7:05 AM
To: [email-masked]
Subject: Re: Link rel attribute "stylesheet"

On Feb 26, 2006, at 9:10 PM, James Yenne wrote:
> 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?)
>
> 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

---

From: James M Snell <[email-masked]>
Date: Mon, 27 Feb 2006 08:33:18 -0800

James Yenne wrote:
>[snip]

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

---

From: "James Yenne" <[email-masked]>
Date: Mon, 27 Feb 2006 09:37:29 -0800

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=http%3A%2F%2Fsoftwareme.com%2Fie7tes
tsubscribed.xml) 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-masked] [mailto:[email-masked]]
On Behalf Of M. David Peterson
Sent: Sunday, February 26, 2006 10:50 PM
To: James Yenne
Cc: [email-masked]
Subject: Re: Link rel attribute "stylesheet"

RSS ' 2.0' are and how and why the Atom specification  fixes these problems.
 
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.

 

*	
line 2
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> , column 252: managingEditor
must include an email address [
<http://feedvalidator.org/docs/error/InvalidContact.html> help]

*	
line 2
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> , column 269: Undefined
channel element: atom:author [ help
<http://feedvalidator.org/docs/error/UndefinedElement.html> ]

*	
line 2
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> , column 370: Undefined
channel element: guid [ help
<http://feedvalidator.org/docs/error/UndefinedElement.html> ]

                                             ^

*	
line 2
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2> , column 643: Unexpected uri
attribute on generator element [ help
<http://feedvalidator.org/docs/error/UnexpectedAttribute.html> ]

*	
line 8
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> , column 181: atom:published
must be an RFC-3339 date-time (3 occurrences) [ help
<http://feedvalidator.org/docs/error/InvalidRFC3339Date.html> ]

*	
line 8
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> , column 216: author must
include an email address (3 occurrences) [
<http://feedvalidator.org/docs/error/InvalidContact.html> help]

*	
line 8
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> , column 445: Undefined item
element: atom:link (6 occurrences) [ help
<http://feedvalidator.org/docs/error/UndefinedElement.html> ]

<http://ww/>  ...

^

*	
line 8
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8> , column 854: Unexpected type
attribute on description element (3 occurrences) [ help
<http://feedvalidator.org/docs/error/UnexpectedAttribute.html> ]

*	
line 19
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19> , column 74: Missing channel
element: description [ help
<http://feedvalidator.org/docs/error/MissingDescription.html> ]

^

*	
line 19
<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FI
E8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19> , column 74: Missing channel
element: link [help  <http://feedvalidator.org/docs/error/MissingLink.html>
]

 
  _____  

correction:

 
On 2/26/06, M. David Peterson <[email-masked]
<mailto:[email-masked]> > wrote: 

Neat idea :)

 

 
 
Thanks,

James 

-- 
<M:D/>

M. David Peterson

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/ 

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Antone Roundy <[email-masked]>
Date: Mon, 27 Feb 2006 10:48:32 -0700

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.
>
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

---

From: "M. David Peterson" <[email-masked]>
Date: Mon, 27 Feb 2006 11:46:27 -0700

On 2/27/06, Antone Roundy <[email-masked]> wrote:
> websites 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"
> 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.

I
> information out of it that could be taken more easily from a

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 server would be required to keep the data feeds up to date from
the various servers in which it subscribes to, but thats not exactly a heavy
handed task, and would also ensure that these files could be scanned for
potential problems using a combiation of virus software for enclosures, and
XML Schema or other Scheman like technologies to ensure that rogue XML
scripts could not be propogated.  If one server can validate this
information for a given set of clients, all of which can trust that this
particular service has gone through the proper processinjg of this data
before sending it to the client, then we save the client-side world from
being required to do the same validation which, of course, would mean an
extensive amount of processing would be saved by simpy putting this trust
into a particular server node in which we know can be trusted.

Of course this is all theoretical at this stage, but it seems to me that
there exists at least some potential somewhere in all of this... finding
that potential, of course, is the key...

Thanks for your help and extemded information!

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Sean Lyndersay <[email-masked]>
Date: Mon, 27 Feb 2006 12:22:49 -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-masked] [mailto:[email-masked]] On Behalf Of James Yenne
Sent: Monday, February 27, 2006 9:37 AM
To: 'M. David Peterson'
Cc: [email-masked]
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=http%3A%2F%2Fsoftwareme.com%2Fie7testsubscribed.xml) 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

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of M. David Peterson
Sent: Sunday, February 26, 2006 10:50 PM
To: James Yenne
Cc: [email-masked]
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.

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-masked]> 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]

                                             ^

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

                                             ^

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

                                             ^

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

                                             ^

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

                                             ^

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

                                             ^

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

^

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

                                             ^

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

^

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

________________________________

correction:

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-masked] > 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" />
<link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format = 'Atom']/@dataFeed" href=" http://www.xsltblog.com/atom.xml " />
<link rel="alternate" type="application/rdf+xml" title="XSLT:Blog/Main[@format = 'RSS+RDF']/@dataFeed" href=" http://www.xsltblog.com/index.rdf " />
<link rel="alternate" type="application/xml" title="XSLT:Blog/Main[@format = 'RSS 2.0']/@dataFeed" href=" 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-masked] > 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/

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Mon, 27 Feb 2006 15:14:09 -0700

Hey cool, Sean!  Ya gotta love this kind of transparency as well as seeking
after bug reports in a proactive gathering sort of way, instead of the
standard "here's the RAID database (speaking in terms of an open, or
partially open RAID db for a given project) -- Enter your bug -- Pray --
Repeat -- Good Luck! :D" in which can sometime feel like what is going on
although I do know that this is not actually the case.  However, for folks
who have never worked on Redmond campus and as such have never seen both the
reality and the positive side of what is actually taking place, I can
empathise with those in whom walk away with similar impressions.  It can
sometimes feel like this is the case, when in fact its not.

That said, its great to see you reaching out proactively to the community
like this.  I can see nothing but positive results because of this, :)

This stuff truly does matter.  Thanks!

Here's a quick extended thanks to all of you who are putting forth this
effort:

The intro can be seen here: http://weblogs.oreilly.com/

The body of the post here: http://www.oreillynet.com/pub/wlg/9257

On 2/27/06, Sean Lyndersay <[email-masked]> 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).
>
>
>
> Sean
>
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *James Yenne
> *Sent:* Monday, February 27, 2006 9:37 AM
> *To:* 'M. David Peterson'
> *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=http%3A%2F%2Fsoftwareme.com%2Fie7testsubscribed.xml) 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
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *M. David Peterson
> *Sent:* Sunday, February 26, 2006 10:50 PM
> *To:* James Yenne
> 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,
> 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
> On 2/26/06, *James Yenne* <[email-masked]> wrote:
>
> ·  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 252: managingEditor must include an email address [ help<http://feedvalidator.org/docs/error/InvalidContact.html>
> ]
>
> ·  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 269: Undefined channel element: atom:author [ help<http://feedvalidator.org/docs/error/UndefinedElement.html>
> ]
>
> ·  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 370: Undefined channel element: guid [ help<http://feedvalidator.org/docs/error/UndefinedElement.html>
> ]
>
> ·  line 2<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l2>,
> column 643: Unexpected uri attribute on generator element [ help<http://feedvalidator.org/docs/error/UnexpectedAttribute.html>
> ]
>
> ·  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 181: atom:published must be an RFC-3339 date-time (3 occurrences) [help<http://feedvalidator.org/docs/error/InvalidRFC3339Date.html>
> ]
>
> ·  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 216: author must include an email address (3 occurrences) [ help<http://feedvalidator.org/docs/error/InvalidContact.html>
> ]
>
> ·  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 445: Undefined item element: atom:link (6 occurrences) [ help<http://feedvalidator.org/docs/error/UndefinedElement.html>
> ]
>
> ·  line 8<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l8>,
> column 854: Unexpected type attribute on description element (3 occurrences)
> [ help <http://feedvalidator.org/docs/error/UnexpectedAttribute.html>]
>
> ·  line 19<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19>,
> column 74: Missing channel element: description [ help<http://feedvalidator.org/docs/error/MissingDescription.html>
> ]
>
> ·  line 19<http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fpublic.activera.com%2FIE8071823f-4ea0-4f62-8ab3-4bbe9f93fb21.xml#l19>,
> column 74: Missing channel element: link [help
> <http://feedvalidator.org/docs/error/MissingLink.html>]
>
> On 2/26/06, *M. David Peterson* <[email-masked] > wrote:
>
> Neat idea :)
>
>
>
> = 'Atom']/@dataFeed" href=" http://www.xsltblog.com/atom.xml " />
> = 'RSS 2.0']/@dataFeed" href=" http://www.xsltblog.com/index.xml " />
>
>
>
> On 2/26/06, *James Yenne* <[email-masked] > wrote:
>
> a fully qualified URI relation does the job too.   I would like to request a

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Sam Ruby <[email-masked]>
Date: Mon, 27 Feb 2006 17:29:19 -0500

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