MS embraces RSS
So, Microsoft announced their RSS announcements:
- IE 7 will do feed autodiscovery.
- Longhorn will have an OS-level subscription list, download service, and parsing service.
- The Simple List Extensions, curiously plural though it looks like a single extension with four elements to me.
Some first thoughts:
Autodiscovery: The funniest part about this to me is that I’ve only seen it described as “like Safari RSS.” Maybe that’s because displaying a transform of the feed is the most obvious part of it, but I seem to recall another browser that did pretty nice autodiscovery, too, and earlier. Poor Opera, always the Rodney Dangerfield. Maybe they should have done pretty-printing, instead of just asking if you want to subscribe, and putting an autodiscovery icon in the chrome. (Firefox gets virtually no credit until it starts detecting when you click the link to a feed, not just autodiscovery links served up to it on a silver platter.)
Platform services: this makes life very good for people writing Windows-only, Longhorn-only aggregators, and having those people exist makes life good for Microsoft. No surprise there. This is also the point where a conspiracy theorist would expect to get locked in the trunk, with a parser that only passes on the elements that Microsoft approves of, so that supporting any non-approved extension means that you have to write your own RSS parser from scratch instead of just making a call to the OS. Nicely enough, they say they aren’t going to do that (The Item object contains an enclosure as well as item properties. It is also possible to get at the actual item xml for such applications which want to perform operations on the xml instead of using the item’s properties.
), only requiring that you parse out the odd bits you want from the raw XML, while you get the standard stuff from the preparsed object (or maybe the object reflects all the extension elements, too: that isn’t too clear). If your aggregator cooperates with the platform services, then you get feeds downloaded during idle times by the rather nice Background Intelligent Transfer Service that also does Windows Update downloads; if you don’t then you stomp all over the connection, slowing things down and being a bad citizen. And with a single shared subscription list, you can have an aggregator, live bookmarks, an iPod synchronizer, and a WinAmp playlist writer, all with partly-overlapping subscriptions without needing to download the same feed more than once. Of course, anything that’s supporting older versions of Windows will need to pile on the ifs, and anything that’s cross-platform will need to stock up on extra #ifdefs, but I don’t think anyone really expected them to do Firefox and Thunderbird any favors.
Simple List Extensions: ouch. That crunching sound you heard was me getting bit on the butt, hard. I’ve written a fair bit of RSS parsing code in PHP that does really simple, naive things with PHP’s SAX parser (a method that’s apparently fairly strange to MS, which seems to do a lot more DOM parsing), where I just keep track of whether I’m in the <channel> or inside an <item>, and assume that any element I recognize is a child of one or the other. Bad news for me.
If you want to say that you are doing an MS Simple List in an RSS feed, and you want the items sorted by title, you would say something like:
<rss version="2.0"
xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005">
<channel>
<title>Phil Ringnalda's List Feed</title>
<cf:treatAs>list</cf:treatAs>
<cf:listinfo>
<cf:sort>
<title data-type="text">The title of the item</title>
</cf:sort>
</cf:listinfo>That title element in the cf:sort element is the one with teeth. My SAX parser goes along, notifying me whenever an element is opened, and again when it is closed, and when the channel opens I say $in_channel = true;, and leave it that way until I see an item open. Then, when I see a title element, if $in_channel is true I use its content as the title for the feed, so I’ll wind up calling that feed “The title of the item.” And since I didn’t invent that style of RSS parsing, I’m not going to be the only one getting bit.
Unfortunately, I don’t see how they could have avoided it: I don’t really know much about XML other than what I’ve taught myself, but I think maybe this is one of the reasons why people who do know about it are always saying that namespaces are horribly broken. To let you say that items should be sorted by any element you choose, they have to let you name the element, and since namespace prefixes aren’t supposed to be significant, the XML could pass through something that changes them, so that either <cf:sort key="dc:date"/> or <cf:sort>dc:date</cf:sort> would become meaningless when an intermediary rewrote the file to use <ab732e5:date> instead. Unless you are naming the element to use as an element, it’s not guaranteed to wind up still pointing at the thing you mean. Suck to be me, and time to start doing it right, with a stack of all the open elements instead of just a boolean. Or maybe time to stop writing my own RSS parsing code.
Phil: Thanks for the practical example… I was wondering how many blogs I’d need to click through before I found something concrete. (Answer: four.)
Am I the only one wondering why they didn’t just come up with generic @data-type and @humanname attributes to ride atop other elements? Despite all this Creative Commons stuff, it seems kinda hostile to found the extension on the notion of repurposing other folks’ elements.
I dunno… I could easily be wrong, but isn’t it a bit screwed up that I could pull out all of the dc:dates in a document and discover that one or more of them is carrying the string ”My Very Kewl Date” as its content?
It sure seems odd to me. I was a little surprised to find that the validator doesn’t choke on such a thing. Apparently we don’t actually have anything that says what the content of
dc:dateshould be, only what the content of<rdf:RDF><item><dc:date>should be, and once you insert one of your own elements in that chain, you then own the right to specify the contents of child elements that are in someone else’s namespace. If I had to point to a bit in some spec which says that’s the case, I’d be very hard pressed to find anything. I’m assuming that Microsoft has any number of people who know far more about XML than a completely self-taught amateur like me, so I guess it’s probably right, but it sure doesn’t feel right.RSS has had lists (trees, tables etc etc) since 2000, remember RDF?
”…you then own the right to specify the contents of child elements that are in someone else’s namespace…” – where’s that from? It seems way off the mark. See XML Namespaces: ”These considerations require that document constructs should have universal names, whose scope extends beyond their containing document.” The key word being *Universal*.
The DC spec says ”Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and includes (among others) dates of the form YYYY-MM-DD.”
I agree the data typing does seem strange, Roger’s suggestion would make more sense (see: @rdf:datatype, @rdfs:label).
PS. the sorting/typing approach seems to be essentially that of architectural forms. Very few XML formats I’m aware of follow this approach, as it requires the extra layer of interpretation.
OPML is a notable exception, except it lacks a useful way of declaring the interpretation in a globally unambiguous fashion – essentially type=”xxx” is whatever you like (as long as Dave approves, anyone paranoid about lock-in should take note).
You’re being extraordinarily charitable in saying that ”I’m assuming that Microsoft has any number of people who know far more about XML than a completely self-taught amateur like me, so I guess it’s probably right.” This example qualifies as a clever hack at best, and severe namespace abuse at worst. This because RSS has a namespace as well, although I gather there is some controversy as to what it should be. So the ”title” tag is qualified with a namespace, creating a unique name with specific semantics. Just sticking that same tag somewhere else with different semantics is just plain wrong, hence the problem you are encountering.
More correct would be something like:
<cf:sort element=”title” />
<cf:sort element=”dc:date” />
etc.
The first example doesn’t specify a namespace prefix, so it should be assumed that it is qualified with the default namespace of the current document (i.e. the RSS namespace). In the second example, the Dublin Core namespace is specified explicitly, so ”ab732e5:date” wouldn’t match, nor should it. It’s a totally different tag.
Furthermore, it should be noted that the approach of ignoring tags outside of the document’s default namespace is part of RSS 2.0, not XML itself. Thus it is unfair to use this as proof that XML namespaces are broken (I really don’t believe they are). In fact, I’m not even averse to taking the RSS 2.0 approach to namespace (RELAX NG, for instance, does the same). People just need to understand that when you see a naked local name like ”title”, it is invisibly qualified by a namespace, and act accordingly.
In terms of your RSS parsing hack, can’t you just set the title from the first (i.e. correct) title tag and ignore any subsequent tags if the value is already set?
I hadn’t looked at the white paper yet, but oh lordy that’s awkward. Sorry, I know I’m an RDFer and in this world, we should be seen and not heard–wait, we should be not see or heard–but lordy that’s clunky.
Matthew, Phil can qualify his work and add yet more conditions to his processing, but seems to me that Microsoft has said that its extensions wouldn’t impact on those who weren’t interested in the data.
Seems to me this is an impact.
Absolutely, it’s an impact. The question is whether it’s an impact like the way adding a namespace to RSS 2.0 broken one person’s parser in just the way it should have broken it, a breakage that should have been expected and should have been fixed at that parser, or an improper impact. Maybe if you want to refer to another XML element that way, you should be required to specify it as two attribute values, namespace URI and localname, and elements should always have the content their specification says they should have, no matter what their parents. I really don’t know, if they are right or wrong to do what they’ve done.
Errm, the RSS 2.0 vocabulary does not have a namespace, there’s no default namespace declaration, ”invisible” qualification doesn’t appear anywhere in any of the relevant specs.
There is an issue here though – it isn’t clear whether the MS spec is talking about local name ”date”, qname ”dc:date” or full name ”http://purl.org/dc/elements/1.1/date”.
[Sorry, out of sequence there – I was responding to Matthews comment]
OPML is a notable exception, except it lacks a useful way of declaring the interpretation in a globally unambiguous fashion – essentially type=”xxx” is whatever you like (as long as Dave approves, anyone paranoid about lock-in should take note).
If you were in the beta test for OPML Editor, you’d see that Dave’s encouraging people to extend OPML with new values for type.
I’ve been wondering when an RSS 1.0 advocate would start talking about how it can be used to specify the sequence of RSS items. I don’t know this new Simple List proposal well enough to see if they’re essentially doing the same thing as that Seq element.
Approximately five minutes after Dave said they were going to announce an extension dealing with lists. At least that’s when I first saw RSS 1.0 mentioned.
But it’s not the same thing at all: the RSS 1.0 Seq says ”this is the one true sorting order for these items” while SLEx says ”these items form a data table, and these are the columns of that table which it’s reasonable to allow the user to sort based on.” I’m sure that could be implemented in RDF, and I’m also sure that if you gave ten RDF experts the task, you would get ten uninteroperable different solutions, each of them absolutely correct to use with no specification, thanks to RDF’s focus on saying anything without worrying about being understood.
”But it’s not the same thing at all: the Relational Model sort order says ”this is the one true sorting order for these items” while SLEx says ”these items form a data table, and these are the columns of that table which it’s reasonable to allow the user to sort based on.” I’m sure that could be implemented in The Relational Model, and I’m also sure that if you gave ten Relational Model experts the task, you would get ten uninteroperable different solutions, each of them absolutely correct to use with no specification, thanks to The Relational Model’s focus on saying anything without worrying about being understood.”
Are hierarchical databases grand? Almost as good as networked.
You can also add: ”… if you gave ten XML experts the task, you would get ten uninteroperable different solutions…”.
Or two at least – Dave’s decided he doesn’t like the MS format after all (and didn’t inhale in the April meeting ;-).
The difference is that you would get ten XML format specifications, and to use them you would only have to find them (and at worst, find the largest set that don’t contradict each other), while your ten RDFers just published ten (or ten thousand) bits of RDF. Going back to my grand failure, if you can tell me how I should have been able to handle having Ben stick a foaf:Person inside dc:creator, without expecting it, without knowing that it was possible, and without knowing what literals he might or might not use in that foaf:Person, and without knowing what other class someone else might stick in there next, and without knowing what literals within it might roughly be what I wanted, a bloody name, then I’ll let you claim some magic extensibility fu in peace.
Sorry Phil, I can’t parse that first sentence at all. The second isn’t much clearer, but I’ll try. So Ben sticks a foaf:Person inside dc:creator, whether or not you knew it was possible your parser could read the data into your store. So your system doesn’t understand foaf:Person. But it might understand foaf:name. So you have:
X dc:creator {something}
{something} foaf:name ”Phil”
So you didn’t understand foaf:name? Well it’s a subproperty of rdfs:label (which is core vocab every viewer tool should understand). So you can infer:
X dc:creator {something}
{something} rds:label ”Phil”
So X is related to something which can be labelled ”Phil”.
You would normally have more information than this up front. Or you might not have all the information today, but get extra information tomorrow (like the human labels for foaf:name and foaff:Person mean) which will help you make more sense of the data.
It’s magic *without* a shared data model, the situation you’re in with RSS/XML extensions alone. With a model it’s a simple matter of programming.
Phil, the gibberish Danny gave sums up to be ”you’re right, without the schema author telling you whether you’d get a literal value or an object, you’re most likely SOL.” RSS/RDF specified literal values (#PCDATA) but provided examples of rich content so that non-RDF parser users might at least be able to recognize and test for when they might receive non-literal content.
There’s an RDF technique called ”dumbing down” where if you want, say, a literal value and you’ve been given an object, there’s a process to get ”the most relevant” literal value from the object. It does require an RDF parser, and one with quite a few smarts, and resolvable references for all the RDF schemas used.
Danny, maybe you can provide a working code snippet?
Yup, on re-reading, gibberish is the word ;-)
I haven’t heard anyone talk of dumbing down around RDF for ages, just doesn’t seem to have come up. But you’re right, in this case you could collapse back some complicated bunch of stuff which your system didn’t understand into whatever simple literals were available.
Ok, I’ll put ”code sample(s)” on my to-do list… fwiw, mnot’s sparta.py looks like it’s heading for being the most easy-to-grok RDF API.
Not sure anyone’s still reading this thread, nor that anyone cares, but RSS 1.0’s built-in rdf:Seq is not really relevant.
The RSS 1.0 working group wanted ”property ordered” items from the beginning, ie. whatever properties the consumer or producer chose to order by. We wanted dc:date order to be the default, but no backwards-compatible 0.91 feed had a date field. The ”core” rdf:Seq solved two independent problems: 1) it made the relational connection between channels and items, and 2) provided the default ordering inherent in and backwards compatible with 0.91 feeds.
The intent that arbitrary property order was intentional was never communicated well. No RSS/RDF ordering extensions were ever proposed to my knowledge.
Even if everyone else is gone, there’s always me and the random future googler. Can’t speak for them, but I’m always happy to hear from you.
rdf:Seq (more as another, than as the child of the items element) also came up in the Longhorn RSS blog, though Danny’s reply is easier to read in his own blog (I hate having to guess what to do to use or escape markup with blogging engines that don’t provide comment preview; even worse than the ones that provide preview that doesn’t handle escaping and markup the same way that submission does).
It’s quixotic as can be, thinking that everyone will fill their RSS 2.0 and Atom with
rdf:datatypes because it makes for better RDF, but damn it does my heart good to see him pull on the armor, straighten out the lance, and charge off at the next windmill.Oh, well, we can just skip threading this time around ;)
Sadly true that RSS 2.0 has no namespace, an albatross I wear around my neck. Not really a problem in this case, though: when you speak of ”the title element in no namespace” you mean the RSS title, when you speak of ”the title element in the http://example.com/foo namespace” you mean another.
However,
ab732e5:dateis a problem. Just because you write your XML file withdc:datedoesn’t mean it will retain those exact characters. Any intermediary along the way, say an OS-level parser, is completely free and utterly correct to reserialize your<dc:date>as<ab732e5:date xmlns:ab732e5="http://purl.org/dc/elements/1.1/">, and it isn’t required to do string matching in attribute values and change them. So the only way I can see to point at another element in an XML document without using the element itself would be with the awkwardAt which point the format designer says ”Dude, if you can’t keep track of a stack of open elements so you know whether you’re getting the element where it should be or somewhere else, you should probably give up on parsing XML.”
I stand corrected on the RSS namespace thing. I was convinced that the spec had a namespace because a) when I googled around I found plenty of examples of RSS documents that do declare an RSS namespace (though the actual URI used varies) and b) it’s so utterly stupid and wrong that it doesn’t. But no matter, I agree with what you say: ”title” is still a unique identifer, namely ”{}title”, and must be treated as such.
With regard to the date issue: internally you should process dc:date as {Dublin Core URI}date. The prefix/namespace mapping *must* be declared in element scope. If some intermediate processing changes the prefix, it must also change the corresponding namespace declaration. In other words, there is a standard way to declare this mapping as per the namespace spec, so why would you need an ad hoc attribute (”cf:namespaceURL” in your example) to do same?
Admittedly this places some additional burden on your parser (which could be handled internally by a schema-aware processor). What’s the alternative? Fully expanded URI/localName pairs everywhere? There are a lot of drawbacks to that as well (particularly extremely verbose and hard-to-read documents). In balance I agree with the prefix approach.
> I was convinced that the spec had a namespace because a) when I googled around I found plenty of examples of RSS documents that do declare an RSS namespace (though the actual URI used varies)
You must be new here.
Rogers, how do you deal with naming clashes in OPML’s type attribute? (If it’s using URIs I might even start using the stuff myself ;-)
Phil – yep, you’re right, it’s the old evil qnames thing again.
Is there any good reason RSS 2.0 shouldn’t use rdf:Seq (or maybe rdf:Collection would be better) along with rdf:datatype? It’d save reinventing the wheel and make translation to RSS 1.0 easier.
Wouldn’t
<cf:listinfo>
<cf:sort element=”title” data-type=”text”>
The title of the item
</cf:sort>
Be cleaner? And if it were Atom
<cf:listinfo>
<cf:sort element=”title” ns=”atom’s NS URI” type=”text”>
The title of the item</cf:sort>
Why not (for Atom):
<cf:listinfo>
<cf:sort element=”http://atoms-NS-URI.org/ns#title” type=”text”>
The title of the item</cf:sort>
I assume you mean that the content of @element is namespace-URI + ”#” + localname. That gives me a very bad feeling about the odds of successful formation and separation of http://example.org/ns2#. Not only would I expect to see more http://example.org/ns2#element than the correct http://example.org/ns2##element, I’d expect morons like me to think that the pair could be decomposed with
explode("#", $attrib["element"]).Or did you mean the content of @element is ”namespace-URI + localname if namespace-URI ends in ’#’ or ’/’ or namespace-URI + ’#’ + localname if namespace-URI ends in any other character”? Bleah. Are attributes really that expensive?
(I made (at least) two copy-paste mistakes with your http://purl.org/dc/elements/1.1/date from up thread, while typing examples in comments I decided not to make, because I kept forgetting that I was copying the URI of an element, rather than the URI of a namespace. But maybe I’m the only one who makes that mistake.)
(If anyone has a copy of An Index to Canonical Instances of xml-dev Permathreads, I could use one.)
Rogers, how do you deal with naming clashes in OPML’s type attribute?
I don’t think that we do. I’d be interested in finding a way to better support extensibility.
Is this thread a parody discussion? I can’t believe people are proposing QNames in Content as the right way to do anything.
Every half decent XML jockey knows they are a disaster and it is a mistake they were ever introduced into the XML world. The sanitized explanation is at Using Qualified Names (QNames) as Identifiers in XML Content
I guess I’m the guy who suggested use of QNames in content. And I totally stand by this. I don’t see anything in the document you refer to that would prescribe this. In fact, it states explicitly:
”In attribute values and element content, QNames are often used to identify a particular element type; they are, in principle, using QNames as they were intended.”
Perhaps I was clear not enough that the prefixes used in such QNames must be declared in document scope and expanded in the internal model to the correct namespaceURI/localName pair. As long as this is respected, the names will be unique and serve exactly the purpose I was suggesting (i.e. uniquely referring to a type name). I can’t think of a better way to do this… certainly *not* the MS approach cited in Phil’s original post.
The document you reference is railing against something totally different (i.e. using QNames for unique names that are not XML type names, like functions in XSLT). In fact, the last sentence explicitly validates the approach I suggested. Read it again.
> Is this thread a parody discussion?
Indubitably.
> I can’t believe people are proposing QNames in Content as the right way to do anything.
Then you’ll love this: http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#col_Role
Aw, c’mon Mark! You can’t compare that abomination to what I was suggesting. At least I don’t think so: I couldn’t understand a word of it. ;-)
In case anyone’s interested, I wrote up an extended take on my views on this matter. I know a lot of people don’t like schemas, which is fair enough, but we should at least recognize that, at the end of the day, that is what this debate is actually about.
Phil (and everyone else) – great feedback. I just posted to our team blog about this, and I’m ready to make an update to the specification to make it easier for you (and everyone else) to parse and understand.
Thanks for kicking off the discussion…
Well, actually I see one suggestion of QNames in content, and several mild suggestions that perhaps rather than concluding from that TAG finding that the content model for any element may be perverted as long as it’s a child of your element, perhaps you should consider representing a {URL, local-name} pair (which is what a QName represents) as a URL and a local-name.
I wouldn’t give even the tiniest bit of weight to my self-effacing suggestion along those lines, but what with Tim having still been on the TAG at the time of that finding, and that whole ”inventor of XML” thing, I’d find his suggestion of the same thing more difficult to ignore.
Grr. Now I’ve lost the ability to remember to thread threads. Picture a piece of string running up to Dare’s comment…
I didn’t finish my post…that’s what I get for rushing out to catch one of the few nice weekends of the year.
Anyway, QNames in content are a bad idea but using a pair of URI and local name like Tim suggests seems like a good suggestion.
I shot of a mail to Sean about this a few hours ago and it looks like he’s already responded
You got out? You bastard! I had to work today, thus the spotty and disconnected nature of my comments. Once I saw that Sean had already responded between the time I failed to click my ”Reply to this” link and the time I growled at you, I figured it was time to shut up and read around for a while (a decidedly unsatisfactory thing to do, as most people seem busy focussing on one misinterpretation of an aside about an unimportant tangent or another; glad it’s not my baby whose sock elastic is being debated at great length with furious heat).
Microsoft and RSS
The big news at the Gnomedex conference, as expected, is Microsoft’s moves to support RSS (Really Simple Syndication) in Longhorn, the next version of the Windows operating
Microsoft’s on the road to ROME too
Microsoft made a series of RSS related announcements this week. They, like many others, have realized that RSS is not just for blogs anymore. It’s for everything from package tracking, monitoring network events, distributing files, synchronizing calendars
Quick postscript on the Microsoft announcement
I read Phil Ringnalda’s post last night at 1AM after getting back from the schmooze, and I pretty much agree with what he said about the Microsoft extensions to RSS 2.0.
The Longhorn RSS team are blogging
Yesterday’s Gnomedex demos by the Longhorn RSS team (who also chose that moment to come out of stealth…
RSS en LongHorn
Desde luego, parece que ha habido flechazo. Microsoft anuncia soporte nativo de RSS en LongHorn, su próximo sistema operativo cuya beta deberÃamos ver aparecer dentro de este año. Si ya avisaron del Desde luego, parece que ha habido flechazo. Microsoft anuncia soporte nativo de RSS en LongHorn, su próximo sistema operativo cuya beta deberÃamos ver aparecer dentro de este año. Si ya avisaron del <a href="http://www.error500.net/microsoft_llega_p
XML Qualified Names: Good, Bad or Indifferent?
A couple of days ago, Phil Ringnalda published a short review of Microsoft’s newly unveiled RSS support. Among other things, he noted that their syntax of their sorting element broke his quick-and-dirty parser, because it includes an actual instance of…
Web 2.0 Weekly Wrap-up, 20-26 June 2005
This week: Wrap of Microsoft RSS news, reblog/reblg, Attention, Yahoo 360 go-live, Late Show style Top Ten for Web 2.0.
Undecipherable Specification Error
What happens when the authors of the feedvalidator can’t decipher a specification? All specs have ambiguities, and authors of validators tend to worry about details that others don’t. For example, what happens if a single rss item contains
La guerre du RSS multimédia aura-t-elle lieu ?
Yahoo, Microsoft, Apple. Ces trois sociétés ont un point commun. Celui d’avoir développé un module d’extension du format RSS 2.0. En mai, Yahoo! introduisait mediaRSS (mRSS), une série de balises décrivant les différents attributs d’un fichier multiméd…
Apple’s standard
Microsoft recently suggested an extension to an important emerging standard, RSS. They used a grass roots industry conference to discuss their extension before shipping any product which used it and quickly received comprehensive, constructive feedback…
Microsoft’s Simple List Extensions Specification Updated