Re: XSLT: Sample implementation

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Pete Prodoehl
David House wrote:
> Some problems:
>
> 2) Atom support isn't there. Firefox and Konqueror (the browsers I
> tested in) get scared off by Atom's mime type and prompt the user to
> download it. They don't recognise it as XML, so they don't transform
> it. We have two options here: give up or serve as text/xml (I guess
> the latter won't be too popular). Really, browsers should recognise
> application/atom+xml as something they can parse as XML and do so.

That's why I eventually gave up using application/rss+xml and switched
to text/xml for RSS. Maybe it's time to do the same for Atom?

Pete




_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Danny Ayers
On 1/30/06, Pete Prodoehl <[hidden email]> wrote:

> David House wrote:
> > Some problems:
> >
> > 2) Atom support isn't there. Firefox and Konqueror (the browsers I
> > tested in) get scared off by Atom's mime type and prompt the user to
> > download it. They don't recognise it as XML, so they don't transform
> > it. We have two options here: give up or serve as text/xml (I guess
> > the latter won't be too popular). Really, browsers should recognise
> > application/atom+xml as something they can parse as XML and do so.
>
> That's why I eventually gave up using application/rss+xml and switched
> to text/xml for RSS. Maybe it's time to do the same for Atom?

Noooo!

The mime type tells you it's Atom, that is a Good Thing. Atom is
designed for Atom clients, not HTML browsers. I've pinged the Atom
list asking if there are any known workarounds (using conneg would
probably be doable, but more trouble than its worth...)

The case with RSS 2.0 is slightly different, as it doesn't have a
registered mime type (if I remember correctly, application/rss+xml
was briefly championed early on, but as the simple fork of RSS didn't
have a convincing spec it wasn't accepted by IANA). RSS 1.0 has
application/rdf+xml.

Cheers,
Danny.

--

http://dannyayers.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

David House
On 30/01/06, Danny Ayers <[hidden email]> wrote:
> The case with RSS 2.0 is slightly different, as it doesn't have a
> registered mime type (if I remember correctly, application/rss+xml
> was briefly championed early on, but as the simple fork of RSS didn't
> have a convincing spec it wasn't accepted by IANA). RSS 1.0 has
> application/rdf+xml.

Makes sense. I'd like to avoid sending Atom as text/xml if at all
possible. As you mentioned, this is less established for RSS and
indeed we do serve it as text/xml already.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Scott johnson-5
For what its worth I captured screen shots of FeedBurner across PC and Mac
platforms (alas I haven't uploaded them yet).  The verdict of the testing
was (works = graphical content not raw tagged text):

url tested: http://feeds.feedburner.com/SoftwareOnlyExt

Mac
* FF 1.5 works
* Camino Current Version works
* Safari doesn't work -- it detects that its a feed and defaults to their
RSS view

PC
* IE 6 works
* FF 1.5 works
* FF 1.0 works

Linux (current ubuntu on my thinkpad)
* FF 1.0 works
* Konquerer does not work

I never got to Opera.  Anyone ever looked at Feedburner in Opera?  And while
I cringe at suggesting something that doesn't work in Konquerer, if we want
to hit volume then duplicating the implementation scheme (but not
necessarily display) of FeedBurner will do that.

S

On 1/30/06, David House <[hidden email]> wrote:

>
> On 30/01/06, Danny Ayers <[hidden email]> wrote:
> > The case with RSS 2.0 is slightly different, as it doesn't have a
> > registered mime type (if I remember correctly, application/rss+xml
> > was briefly championed early on, but as the simple fork of RSS didn't
> > have a convincing spec it wasn't accepted by IANA). RSS 1.0 has
> > application/rdf+xml.
>
> Makes sense. I'd like to avoid sending Atom as text/xml if at all
> possible. As you mentioned, this is less established for RSS and
> indeed we do serve it as text/xml already.
>
> --
> -David House, [hidden email], http://xmouse.ithium.net
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



--
-------------------------------------------------------
J. Scott Johnson
Ookles launches 2/28/06 - have you signed up yet?
new startup: http://ookles.com/
blog: http://fuzzyblog.com/
podcast: http://techwarstories.com/
[hidden email]
aim: fuzzygroup
cell: 857 222 6459
-------------------------------------------------------
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

David House
In reply to this post by Pete Prodoehl
On 27/01/06, David House <[hidden email]> wrote:
> 2) Atom support isn't there. Firefox and Konqueror (the browsers I
> tested in) get scared off by Atom's mime type and prompt the user to
> download it. They don't recognise it as XML, so they don't transform
> it. We have two options here: give up or serve as text/xml (I guess
> the latter won't be too popular). Really, browsers should recognise
> application/atom+xml as something they can parse as XML and do so.

Right, this has been discussed on #wordpress and we think the best
solution would be to send application/atom+xml to clients with that in
their Accept string, and text/xml to everyone else. We also demand
that feed readers start sending an Accept header.

A quick survey was conducted as to which readers Accept
application/atom+xml. Sage, Akregator does, FeedDemon doesn't send
Accept at all. We need more people testing different clients.

A quick note: this won't break any feed readers. There are plenty of
people out there serving Atom as text/xml already so feed readers have
to support it. It's not the right thing to do, hence us demanding feed
readers start Accepting application/atom+xml, but we've no choice.

Incidentally, most browsers Accept */*, so we'd have to only send
application/atom+xml to those clients that _specifically_ Accept
application/atom+xml.

Right. Now we need an implementation.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Matt Read
On January 30, 2006 01:14 pm, David House wrote:

> Right. Now we need an implementation.

Here's a diff for wp-atom.php to do just such that. Sends text/xml if the
user-agent doesn't accept application/atom+xml.

Could be cleaned up a bit maybe put in a function or something but here it
is... test away.


--
Matthew Read
http://www.mattread.com/

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Matt Read
In reply to this post by David House
My attachment got scrubbed, so here it is as .txt

On January 30, 2006 01:14 pm, David House wrote:
> Right. Now we need an implementation.

Here's a diff for wp-atom.php to do just such that. Sends text/xml if the
user-agent doesn't accept application/atom+xml.

Could be cleaned up a bit maybe put in a function or something but here it
is... test away.


--
Matthew Read
http://www.mattread.com/

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers

wp-atom.php.txt (854 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Owen Winkler
Matt Read wrote:
> On January 30, 2006 01:14 pm, David House wrote:
>> Right. Now we need an implementation.
>
> Here's a diff for wp-atom.php to do just such that. Sends text/xml if the
> user-agent doesn't accept application/atom+xml.

Why I like this idea:

It shouldn't break things- Clients may care to ask for a specific
mimetype, but in the end, they're likely to accept anything as long as
it's XML-valid.  Readers that ask for the non-browser mimetypes will get
them.

It lets us put browser-targetted content into the feeds- Now, since
text/xml is served to browsers, we can put in the XSLT stuff that makes
the feed prettier in some browsers.  (I still like my own solution,
which is to not display the feed data at all, instead displaying
two-frame frameset: A top frame with a "this is a feed, use a
feedreader" notice, and the bottom frame with the actual blog home page
in it.)

It should make proponents of feed mimetypes happy - Why?  Because it
should promote the use of the correct mimetype for requesting feeds.

Indeed, Matt's other code (as seen in a pastebin) is even better,
because it decides what feed format to present to a client based on the
Accept request header and not the request URI.  So if your client likes
Atom best, it would request from http://example.com/feed and get Atom.
A different client could point at the same URI and get RSS 2.0 or RDF,
depending on the q of the Accept.  Very nifty.

If interested parties people could comment on why this might suck, that
would be useful.  Really, I think this is pretty neat.

Owen



_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Robert Deaton
On 1/30/06, Owen Winkler <[hidden email]> wrote:
> <snipped> (I still like my own solution,
> which is to not display the feed data at all, instead displaying
> two-frame frameset: A top frame with a "this is a feed, use a
> feedreader" notice, and the bottom frame with the actual blog home page
> in it.)

+1 on that whole idea, much better than the styling feeds bull.

> Indeed, Matt's other code (as seen in a pastebin) is even better,
> because it decides what feed format to present to a client based on the
> Accept request header and not the request URI.  So if your client likes
> Atom best, it would request from http://example.com/feed and get Atom.
> A different client could point at the same URI and get RSS 2.0 or RDF,
> depending on the q of the Accept.  Very nifty.

+1 I love this idea, but I'm not entirely sure how well it'll work,
but its worth a shot while in testing to gather feedback, and if no
major problems arise, I'd definately encourage this as a 2.1 feature.

--
--Robert Deaton
http://somethingunpredictable.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Jeff Minard
In reply to this post by Owen Winkler
Owen Winkler wrote:
> Indeed, Matt's other code (as seen in a pastebin) is even better,
> because it decides what feed format to present to a client based on the
> Accept request header and not the request URI.  So if your client likes
> Atom best, it would request from http://example.com/feed and get Atom. A
> different client could point at the same URI and get RSS 2.0 or RDF,
> depending on the q of the Accept.  Very nifty.

That would go right in-line with the idea (from the other thread) or
using an open source rss library for output parsing.

Jeff
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Phil Ringnalda
In reply to this post by Matt Read
Matt Read wrote:
> Here's a diff for wp-atom.php to do just such that. Sends text/xml if the
> user-agent doesn't accept application/atom+xml.

If what you return varies based on the Accept header, then your response
needs to include a "Vary: Accept" header, so that a cache with one
version doesn't return it to something which would get the other
version. At which point, from what I've heard, most caches will just
punt and not cache it at all, rather than worry about handling the Vary.

And since the purpose of mime-types is to tell general-purpose user
agents how to handle or dispatch an unusual content type, and you know
that the general-purpose user agents aren't going to add
application/atom+xml to their Accept header even if they know how to
dispatch it, while the specific-purpose user agents that will add it
will do the exact same thing no matter what type you return (possibly
short of text/html), why bother? If you would rather work around browser
bugs than work with the architecture of the web, just embrace that
desire, and send application/xml (please, not text/xml, which has a rare
but still very real risk of arriving misencoded) to everything. Caching
(and minimizing the amount of processing required to generate a feed) is
vastly more valuable than sending the correct mime-type only to things
that you know will ignore it.

Phil Ringnalda
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XSLT: Sample implementation

Owen Winkler
Phil Ringnalda wrote:
> Matt Read wrote:
>> Here's a diff for wp-atom.php to do just such that. Sends text/xml if
>> the user-agent doesn't accept application/atom+xml.
>
> If what you return varies based on the Accept header, then your response
> needs to include a "Vary: Accept" header, so that a cache with one
> version doesn't return it to something which would get the other
> version. At which point, from what I've heard, most caches will just
> punt and not cache it at all, rather than worry about handling the Vary.

This header is trivial to add.

> And since the purpose of mime-types is to tell general-purpose user
> agents how to handle or dispatch an unusual content type, and you know
> that the general-purpose user agents aren't going to add
> application/atom+xml to their Accept header even if they know how to
> dispatch it, while the specific-purpose user agents that will add it
> will do the exact same thing no matter what type you return (possibly
> short of text/html), why bother?

Do you disagree that clients should be requesting the proper content
types in their Accept header for the content that they intend to
receive?  Are you really saying that this is useless because clients
will never adopt the content type recommendations that feed pundits espouse?

If a browser client prefers text/html or text/xml, and that content type
is available, shouldn't we serve that instead of application/xml or
application/atom+xml that they didn't specifically request?  As far as I
see, there is plenty of latitude to assume that the request is going to
be one rendered by a browser unless requested with a specific content type.

Why should we bother?  Because if you return a content type that
browsers can display to browsers that prefer it, then the browser will
also be able to render it in addition to whatever other clients request
it.  Not doing this gets us nothing.  Doing this makes the content at
the other end of feeds appear more friendly, which has yet to be
demonstrated to harm anyone.

And regarding caching - How does the content type affect caching at all
beyond the small change to add the Vary header?

We spent a good bit of time thinking about, discussing, and coding this
solution.  It's going to take more of an explanation than saying "why
bother?" and complete lack of an alternative to convince me that this
isn't worth doing.

Owen



_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Loading...