OddThinking

First up, was it XML that was showing up in the orange box, or the even more short-sited RSS? How do you link to Atom when the only icon you’ve got says RSS? I know that Firefox, and later IE7 have both gone for a generic icon instead – Fx opting for radio wave emissions, IE going with … well, the icon Fx 1.5 has switched to using now! I know the orange XML link has its uses: if the target you’re linking to is generated by the server from a source file, you might link to the source file with the orange link too. Another way you might want to do this is via RDDL, as that allows for multiple formats, several of which might be viewable in a web browser. Finally, now that you’re using a blue-toned theme, you might be able to get away with displaying an orange icon. Previously, orange and green would indeed have destroyed any sort of style you were trying to create. Now, you can enjoy the colour scheme used by Firefox 🙂

I get the feeling you’ve misinterpreted the purpose of the title attribute in the link tag. It’s there to be displayed in a text-only browser, or at least one that lets you review the metadata on a page. Because it’s external to the feed, I think Bloglines is right to go and ask the feed what it calls itself. After all, it’s the authoritative source on the matter. It’s WordPress’s fault for not letting you set that text.

I also think that “alternate” is right, in this case, as it is providing an alternate format, not giving you an alternative to choose from (although the line here is a bit grey). Still, they could have sidestepped further pedantry and just gone with “alt”, like any rational person would do.

PS Get with the xhtml new world order, Nitpicker, and abandon this capitalisation fixation: its a link tag, not a LINK tag. xhtml is case sensitive (unlike good ol’ html), as it is supposed to be a machine-machine language, even though that defies all logic when the web is concerned. People write xhtml! Who would have guessed?!

It is more that XML is a technical name for low-level file-format.

Yes. It should say “Subscribe” on it, not “XML” or “RSS”.

(IE6 won’t even open an ATOM feed – you need to save it to disk, and open it as an XML file, but that’s another story.)

First, it’s Atom, not “ATOM.” It’s not an acronym. It’s a proper name that doesn’t stand for anything. (As opposed to “RSS”, which stands for one of a half-dozen things depending on the format version and your mood.)

Anyway, that claim’s wrong. It depends on the MIME type sent by the server, not the file format. For Atom, that’s application/atom+xml, which IE doesn’t know how to handle. RSS 0.9x/2.0 is usually delivered as text/xml (which is considered harmful for various good reasons), which leads to the XML file rendering in the browser. Unfortunately there is no MIME type for RSS. Some people use application/rss+xml – but that isn’t IANA-registered.

Why is that important? Because an application could register itself as being able to handle application/atom+xml, in which case the browser would download the file and start the application in question on it. And since Atom (not the deprecated 0.3 version that WP 2.0 ships, but certainly the RFC4287 version) contains provisions for an <atom:link rel="self" href="..." /> link, that handler application can then find which URL the file came from.

This is how it should work. It’s how listening to web radio streams works: you click on a link that points to a file which gets served with audio/x-mpegurl MIME type and contains a reference to the server; the browser downloads it and, due to the MIME type, fires up your MP3 player with it; the player reads the server address from the file and connects. Voilà.

Feed: isn’t a standard URI-scheme.

Yes. It was a misguided attempt to come up with a mechanism to let other apps handle the link, which happened because RSS did not have an equivalent of atom:link[@rel='self']. Something like Atom’s mechanism isn’t possible then, because once the file is downloaded, the handler application for (say) application/rss+xml cannot find out where it came from. But you can register handler apps not only for MIME types, but also for URL schemes – and such a handler gets to see the URL of the link. So this stupid feed: thing was conceived.

However, that is now discouraged; since RSS is XML, you can just declare the Atom namespace in an RSS document and include an atom:link element. Some aggregators already support that; support is spreading.

I want a more authoritative reference.

There was an I-D for it, which unfortunately is expired now. A new version was supposed to fall out of the work of the Atom WG; I don’t know what happened to that. In any case, it isn’t much more than an application of the semantics of the <link> tag, so there’s no need to worry about that part too much.

What pisses me off something fierce is that WordPress puts feed: links in its autodiscovery links. That’s just wrong, completely and utterly wrong.

Alternate? Oh please! The word you are looking for is “alternative“.

Alternative? Oh please! From WordNet:

alternate

n : someone who takes the place of another person [syn: surrogate, replacement]

Which is precisely the intended meaning.

PS: wish I could’ve used a <dl> list for the definition.

Instead, if fetches the RSS feed itself, and looks inside for the title to use.

Which is the equivalent of throwing hands up. The title attribute is supposed to be a description that helps a human pick which feed they want. Good values would be things like “Articles, full text”, “Headlines” or “Comments.” Bad values are “RSS 1.0”, “RSS 2.0” or “Atom 0.3”. How is a non-technical user supposed to know which of those to pick? Now, guess what titles are used in practice? So what else is Bloglines to do? It resigns to do the least stupid thing.

Nice rant, agree there is much to be done here to make RSS more non-geek friendly. (And I await the little orange “big endian” badge with keen anticipation.)

Disagree that XSLT was designed to prevent raw XML from being displayed to the user. It *could* be used to present a human-readable representation of some XML data, assuming that the data is sufficiently textual. All the XSLT in the world is not going to render a SVG (XML-based vector graphics) picture, for example.

And while wordpress could almost certainly provide XSLT stylesheets for the various RSS flavours it generates, the advantage of doing this would be relatively small, IMHO. As long as the RSS is supplied with the correct MIME type, the responsibility for rendering it to the user lies with the browser. The fact that IE doesn’t give a nice error message is a problem with IE, not wordpress.

One of the problems with being nitpicky is that you instantly lower the bar for pedants wishing to return the favour. So in that spirit: your html is a mess!

Examples: “<p>The keyword for the </code><code>LINK</code> relationship”, also “the typical < <code>a> link tags”

(I don’t know what wordpress is going to do to that but I’m sure you’ll work it out 🙂

Richard: “Alternate” is wrong, I agree with Julian.

Re: The HTML mess, noted by Richard and Alastair.

Fixed.

Sorry – I was having problems going back-and-forth between the new WYSIWYG editor and the HTML editor in WordPress 2.0. I’ve now turned off the WYSIWYG editor until the next version of WordPress.

Unfortunately, WordPress sets that XML field the same for all feeds, so there is no distinguishing marks apart from the URL.

I think I have made a mistake around here, and I owe an apology to WordPress. It does put some title information about the feed in the XML. It distinguishes between a comments feed and a regular (article) feed. It doesn’t distinguish between RSS 0.92, 2.0 and ATOM 0.3.

I think I got confused because my Comments RSS feed was temporarily (or perhaps intermittently?) unavailable. Bloglines was smart enough to hide the bad feed from me, and I got confused by the shortened list where all the names were the same. Sorry, WordPress.

Open question: Should WordPress include the format of the feed in the title to make it possible to distinguish them? I am in two minds, but I mainly lean towards what WordPress is already doing (not including useless info about technology choices in the title of the feed)

I wonder: Would it be legitimate for a feed aggregator, like Bloglines, to recognise that several feeds have the same title but different formats, and display only one of them, rather than giving the user a false choice between competing but equivalent technologies?

Also, Bloglines does recognise the feed: syntax, even if I refuse to! I missed this for the same reason.

Alastair,

All the XSLT in the world is not going to render a SVG (XML-based vector graphics) picture, for example.

I accept your qualification, that XSLT is only useful for mapping textlike-to-textlike.

Although it would be a cute project to produce an XSLT that could map an SVG file to “… and then, just a litte bit above that is a reddish-brown cube. It has sides twice as long as the pyramid I was talking about earlier…” 🙂

However, I think it would be quite legitimate to map an RSS feed or an SVG file, via XSLT, to a static HTML page that says “Hey! You’re trying to look at a file in a browser that was really meant to be read by other software. There is nothing to see here. Move along please.”

I know I have seen this done in practice, but I can’t remember where.

As long as the RSS is supplied with the correct MIME type, the responsibility for rendering it to the user lies with the browser. The fact that IE doesn’t give a nice error message is a problem with IE, not wordpress.

I think IE6 is behaving correctly here. There’s no error message, just unreadable XML!

It recognises application/rss+xml as a type of XML, and displays it as best it can – with pretty syntax colouring, and indenting and everything. It doesn’t realise that it would be more useful to offer to subscribe to this, because IE6 isn’t an feed aggregator. It can’t transform it into a pretty HTML version, because there’s no XSLT link. So it displays it in a developer-friendly, user-unfriendly, but legitimate, format.

It doesn’t recognise application/atom+xml, so it offers to save it to disk so another tool can process it.

It is a fair complaint to say a new version of IE is sorely overdue – one that knows how to properly process these new-fangled MIME types natively – but I don’t blame IE6 for handling them exactly as it does.

I just remembered that Mark Pilgrim did something similar to what you are describing with XSLT and RSS.

Although I haven’t been following it all that closely, I *think* the reason why this and similar techniques are not more widely used is because the auto-discovery of feeds is preferable these days.

I’d written a 2-page response to a bunch of your points here that never showed up. Please tell me it was swallowed by Akismet or something and not lost in a browser hiccup or whatever.

Aristotle:

Yes, it was swallowed by Akismet. I got it to spit it out, and it now appears, up higher in the list. Another strike against WordPress 2.0. I’ll keep an eye on this, and revert to back Spam Karma 2 if required.

Aristotle,

You raise some excellent points – I am sorry your comment was hidden away for a period.

First, it’s Atom, not “ATOM.” It’s not an acronym.

Thank you. I have updated the references. I also updated the references from LINK to link, as requested by Richard.

Anyway, that claim’s wrong.

I am not sure, but I think we are in complete agreement about IE’s behaviour. IE6, out-of-the-box, has no add-on to support application/atom+xml. When it sees one, it offers to save it to disk. Once on disk, the Windows OS rules are different, and it can be opened as an XML file in IE.

Unfortunately there is no MIME type for RSS. Some people use application/rss+xml – but that isn’t IANA-registered.

Ooops! You are right! I am an accessory to this crime.

In the link tag, I have text/xml for RSS 0.92, but application/rss+xml for RSS 2.0. I copied this from another WordPress theme, not knowing any better.

However, in the actual feed file, WordPress 2.0 sends text/xml in the http headers for both, so my the crime is a minor one. I will fix it next time I’m in the area.

Duncan Mackenzie debated this same issue.

Sounds like someone in the RSS 2.0 camp should be pushing through an application or two through IANA!

not the deprecated 0.3 version that WP 2.0 ships

Oh dear. As if I wasn’t confused enough! Another version to consider!

There was an I-D for it, which unfortunately is expired now.

Thanks for the link. That is exactly what I wanted to see (apart from the expiry date!)

it isn’t much more than an application of the semantics of the <link> tag

Agreed, but that is exactly what is required – something that explains to web-designers that they need to use this convention to be interoperable with Firefox, Bloglines, Feedburner, IE7, etc.

What pisses me off something fierce is that WordPress puts feed: links in its autodiscovery links.

You’ll be happy that the latest version of the SomethinkOdd WordPress theme no longer includes these links. I didn’t like them when I first saw them, but I thought it was a new standard. I was more than glad to finally realise it wasn’t a standard – they’re gone!

Good values would be things like “Articles, full text”, “Headlines” or “Comments.” Bad values are “RSS 1.0”, “RSS 2.0” or “Atom 0.3”. How is a non-technical user supposed to know which of those to pick?

I agree, and I still have a bit more work to do here for this blog theme.

However, it still leaves the problem that I am offering several different protocols for the same feed. If I don’t mention the technology in the title, the user will have an even harder time choosing the right one (e.g. in Firefox). I did mention the idea above (after you wrote this comment) that the feed aggregator might discard the duplicates to assist here.

From WordNet

Interesting – it seems some American dictionaries are accepting the usage that used to be considered incorrect (and I, as a curmudgeonly Commonwealther, still see as incorrect!) [Ref]

There are plenty of counter-references that defend my position, especially if we could agree that it is an adjective describing the link, not a noun, in this situation.

Alastair:

All the XSLT in the world is not going to render a SVG (XML-based vector graphics) picture, for example.

Actually, it’s not impossible. You are not restricted to generating XML in an XSL transform; it can be pretty much anything. In practice, of course, XSLT itself doesn’t particularly facilitate this type application since the language is very focussed on one particular kind of task.

As long as the RSS is supplied with the correct MIME type, the responsibility for rendering it to the user lies with the browser.

The problem is that there is no MIME type for RSS, so you can only say it’s text/xml (bad) or application/xml. Now granted, we’re talking about XML, so upon seeing such a file, the browser could peek inside and look for a known namespace (RFC4287 specifies http://www.w3.org/2005/Atom for Atom). Except, RSS is “simple” so it doesn’t use a namespace.

So there really is no way for a browser to hand this to a helper app correctly.

One more reason to make this damn RSS mess a thing of the past and move unilaterally to Atom.

Julian:

Would it be legitimate for a feed aggregator, like Bloglines, to recognise that several feeds have the same title but different formats, and display only one of them, rather than giving the user a false choice between competing but equivalent technologies?

It is. This was actually stated for feed autodiscovery at some point. Unfortunately, there are sites out there which put the same title on multiple feeds which differ not only in format, but also in content. So for now, it’s not possible to do anything really user-friendly with autodiscovery, because the data in the wild is just too ambiguous.

Sigh.

Julian, again:

Another strike against WordPress 2.0. I’ll keep an eye on this, and revert to back Spam Karma 2 if required.

It was really my own fault; I occasionally use numerical character references for things in the low-ASCII range (like dots or dashes) to defeat things like smiley-replacers or, in your case, typographical smarteners. (I didn’t want the three dots in my markup example to be turned into an ellipsis.) To Akismet, a low-ASCII NCR is a sign of spam.

Julian, once more:

I am not sure, but I think we are in complete agreement about IE’s behaviour.

I was not saying IE was doing something else. 🙂 I was just saying that it didn’t have anything to do with the format of the file itself, only with the MIME type sent by the server.

Sounds like someone in the RSS 2.0 camp should be pushing through an application or two through IANA!

Unfortunately, that’s never going to happen. 🙁

One more reason to abandon this RSS legacy.

Another version to consider!

Actually, not really. Atom 0.3 was a transitory format from the start and is now deprecated. It was never an official standard (although that probably means very little in a world where RSS 2.0 sees use). It is being phased out pretty much everywhere. The FeedValidator no longer validates Atom 0.3 feeds. TextPattern 4.0 ships with only Atom 1.0 templates for full text feeds; MovableType 3.2 comes only with Atom 1.0 and RSS 2.0 templates. LiveJournal has moved to Atom 1.0. Of the big installable platforms, only WordPress is lagging behind; of the centrally hosted ones, Blogger. All remotely popular aggregators support Atom 1.0 (though some better than others).

See also:

• Ben de Groot: No Atom 1.0 feed in WordPress 2.0
• Ben de Groot: Let’s get proper Atom support into the next WordPress release!
• WordPress Trac: #1526: have wp-atom.php generate Atom 1.0 (fix attached)

However, it still leaves the problem that I am offering several different protocols for the same feed.

I would standardise on Atom 1.0 and offer nothing else. 🙂

But then, as someone who has his name on RFC4287, I guess I would say that… of course, the reason I got involved that much is because of the unholy mess that RSS is; a situation which clearly is never going to improve.

it seems some American dictionaries are accepting the usage that used to be considered incorrect

Interesting. I didn’t know about that. And as I generally learn towards British English, I guess this will henceforth have to bug me as well. Oh well.

Another reason to hate Javascript-based live preview features: the above comment appeared totally mangled in the preview. I was pretty sure that it would come out correctly, though, and indeed, so it did.

I accept your qualification, that XSLT is only useful for mapping textlike-to-textlike

Actually that’s not quite what I intended. You seemed to be saying that XSLT should solve the problem of providing a human-readable representation of any XML data format for the purposes of displaying in a browser, and I just wanted to qualify that the data would have to be sufficiently textual for this to work.

In case anyone is Googling on “XSLT is useful for”, I think there are many useful applications for XSLT in general (that is, outside the browser) besides “textlike-to-textlike”. For example, one of these days I’m going to write the Apache Ant file to Graphviz DOT XSLT script (for target dependencies in case you were wondering).

Aristotle:

You are not restricted to generating XML in an XSL transform; it can be pretty much anything. In practice, of course, XSLT itself doesn’t particularly facilitate this type application since the language is very focussed on one particular kind of task.

Actually not anything, only XML, HTML and text are supported by the standard (and all current implementations, to my knowledge). Although I guess that with sufficient abuse of the text output method (and a suitably liberal choice of encoding) you might be able to produce any byte sequence you like. Perhaps even exploit a buffer overflow vulnerability… The mind boggles.

Thanks for clarifying about the MIME type, point well taken.

(And yes I agree the live preview is broken).

Whew, I have learnt a lot in this discussion. Let me see if I can summarise with judgemental but pithy opinions.

• Yay to WordPress for supporting many types of subscription.
• Boo to WordPress for not supporting an “everything” (articles+comments feed).
• Boo to WordPress and Blogger for not supporting Atom 1.0, yet.
• Yay to TextPattern, MovableType and LiveJournal for supporting Atom 1.0.
• Yay that it is planned for WordPress 2.1, and people are working on the code.
• Yay to the existence of an Internet Draft for feed auto-discovery.
• Boo that the draft has expired without making it to the next step in the formalities.
• Boo to the orange XML and/or RSS icon for sharing irrelevant technical detail to a nontechnical audience.
• Yay to Firefox (and then IE7) for ignoring the orange XML icon, and for making (and then sharing) a better one.
• Boo that it is still orange!
• Boo to WordPress for the default usage of the nonstandard feed: convention.
• Yay to Bloglines for recognising it anyway.
• Yay to the SomethinkOdd theme that removes all sign of it.
• Yay to the potential of XSLT to make feeds look better.
• Yay to Dive Into Mark for proving it works.
• Yay to the general power of XSLT.
• Boo to the use of text/xml (I have to admit, I am not yet sure why; I am just baying with the crowd here..)
• Boo to the use of non-standard MIME-types, like application/rss+xml.
• Boo to SomethinkOdd Theme that still uses application/rss+xml.
• Boo to IANA for making the registration of application/rss+xml complex.
• Yay to IE6 for handling unknown MIME types gracefully.
• Boo to Microsoft for not providing support for new MIME types fast enough.
• Boo to the use of alternate as an adjective, except in the U.S.A., or if you are a linguist. (I spoke to one, and he told me I was being inconsistent in attacking the noun-modifier in “alternate link” but accepting the noun-modifier in “school hall”.)
• Yay to including information about your feed’s content in the feed, and in the link title.
• Boo to including technical format information in the feed title(s) that confuses non-technical users.
• Boo to not including technical format information in the feed title(s) when you have multiple formats with identical content.
• Boo to not being able to make up my mind on the last two points.
• Boo to pages with multiple feeds with the same title, same format and different content.
• “Oh, what a shame” to the simple WordPress architecture and Auto-discovery headers not really getting along well.
• Boo to Julian for getting confused and blaming Bloglines and WordPress for a serious RSS problem, when it was just an minor and temporary WordPress one.
• “Oh, what a shame” to Bloglines for discarding often-unreliable-but-this-time-useful title information.
• Huh? to RDDL and RDF, neither of which Julian understands yet. You can add OPML to that list too.
• Props to Aristotle for getting a mention in an IETF document.
• Boo to RSS for not having a way of detecting the source of the RSS feed from the file itself.
• Boo to WordPress for not supporting dl links.
• Boo to the SomethinkOdd CSS that doesn’t support dllinks even if WordPress did.
• Boo to Akismet for marking one comment as spam and two more as “needing moderation”. Spam Karma 2 had a much better hit rate.
• Boo to the new WordPress WYSIWYG editor that chewed up my HTML repeatedly.
• Boo to a number of feed aggregators, including Bloglines and Firefox, that don’t conform to the Atom standards for title mark-up.
• Boo to the Live Comment Preview plugin for mangling the display of some comments.

That’s a big list. Did I miss anything?

I don’t know about missing – the list is too long. Most is correct, too, but some of these need elaboration:

Boo to the use of text/xml (I have to admit, I am not yet sure why; I am just baying with the crowd here…)

It’s because:

The accuracy of metadata is inversely proportional to the square of the distance between the data and the metadata. —Sam Ruby

RFC3023 is the key here: text/xml means the document charset is what the HTTP Content-Type header says, or if that doesn’t say anything it’s us-ascii – regardless of what the <?xml?> preamble in the document says. The user agent MUST ignore that. In contrast, application/xml means the charset is what the HTTP header says, or if that doesn’t say anything, it’s what the <?xml?> preamble says; or if that doesn’t say anything, then it’s utf-8.

Note that the HTTP header, if it says something, always takes precedence. But application/xml at least makes it possible to let the document specify its own encoding.

• Boo to not including technical format information in the feed title(s) when you have multiple formats with identical content.
• Boo to pages with multiple feeds with the same title, same format and different content.

Actually, what you’d want is: feeds with identical content should have identical titles. Then software could simply offer a single choice, and sweep all the technical issues under the rug, silently picking what it works best without asking such a choice of the hapless user.

Unfortunately, as I bemoaned earlier, this isn’t currently feasible, because on the web today you’ll find examples for any possible configuration of identical or differing titles for identical or different content in identical or differing feed formats.

• Boo to WordPress for not supporting dl links.
• Boo to the SomethinkOdd CSS that doesn’t support dllinks even if WordPress did.

Hmm? They’re not links, they’re lists – definition lists. dl is much like ul and ol. None of these are among the tags allowed in comments here, which is what I want bemoaned. I don’t know where CSS figures into this.

Huh? to RDDL and RDF, neither of which Julian understands yet. You can add OPML to that list too.

The most there is to know about OPML is that it sucks. 🙂

As for RDF, that’s a large field. It’s not a feed format; RSS 1.0 is defined in terms of RDF, but RDF is basically a framework to represent meta-/data in a completely extensible way. I’m afraid I can’t explain it well, though, because it hasn’t really clicked in my brain yet either. Maybe What is RDF? will help?

Boo to the Live Comment Preview plugin for mangling the display of some comments.

Have I mentioned the AJAX Comment Preview? 🙂 That isn’t “live,” so it doesn’t annoy – no flickering cursor in the textarea, no large page jumps when cut+pasting chunks; and because it defers to the server-side formatter the preview is always 100% accurate, smiley replacements, Markdown or other formatting and all.

Aristotle,

RFC3023 is the key here

I get it now. Thanks. Boo! Boo!

They’re not links, they’re lists

Sorry; I knew that – Just a typo/braino. I figure that, to support dl lists properly, I need to tell my CSS how I prefer them to be formatted. Now that you question me on it, I realise the default is probably quite acceptable.

Thanks too for the RDF and OPML links.

I don’t hate Live Comment Preview, but I guess my readers do, so replacing it (and Akismet, too) is on my list.

Boo to not being able to make up my mind on the last two points.

Yay to making up my mind and removing technical info from feed titles, even if that means some people will see equivalent links twice.

Yay to OddThinking for now using application/xml where it used to use text/xml.

“Oh, what a shame” to the simple WordPress architecture and Auto-discovery headers not really getting along well.

Yay to Julian for waking up this morning with the realisation that there is a simple solution. You just need to run The_Loop twice per page – once for the autodiscovery links, and once for the contents of the post. Inefficient? Maybe, but who cares?

I now have a proof-of-concept up live – each page offers an auto-discoverable feed per post on the page, so you can subscribe to only the comments on a particular post.

Later, I would like to add similar autodiscovery links for category feeds and search feeds.

using a link to the “Alternate” word in the Wikipedia means nothing. Alternate is a word, therefor it appears on a dictionary, as the Wiktionary.

Tnarik,

I can understand your confusion. The Wikipedia article “alternate” is now missing. Linking to a non-existent word in Wikipedia, as you suggest, proves nothing.

However, at the time this was originally posted, the Wikipedia article explained the prescriptivist view that “alternate” was not an alternative to “alternative”. It has since been deleted – probably for the reason you gave – it really belongs in Wiktionary.

Not to flog the dead comment thread, but here’s what Strunk & White have to say:

Alternate. Alternative. The words are not always interchangeable as nouns or adjectives. The first means every other one in a series; the second, one of two possibilities. As the other of a series of two, an alternate may stand for “a substitute,” but an alternative, although used in a similar sense, connotes a matter of choice that is never present with alternate.

As the flooded road left them no alternative, they took the alternate route.

There has been a new effort to register application/rss+xml and the application has been submitted. Let’s see if the procedural problems that prevented success during the last effort have been addressed.

Four years have passed, and I don’t see rss+xml on the IANA Media Types application page.

I haven’t been following to know whether the effort is still proceeding, blocked or abandoned.

Probably abandoned at this point, maybe after initially getting blocked. No one cares any more anyway… the de facto standard is so entrenched it wouldn’t really make a difference in practice anyhow. I was dubious that the outcome would be anything else anyway, considering the history of RSS.