I saw a recent post from Dave Winer berating Yahoo! where he wrote

Yahoo is the strangest most jealous and behind-the-scenes plotting and scheming of tech companies. When any of the other "giants" moves in RSS space I get plenty of advance notice so that I can help them promote it, maybe even make it better before it's announced. Yahoo, as a company seems jealous and insecure, seems to have as a goal, replacing me. Hey it's been tried before, probably isn't worth the trouble. And it's amazing for all the lack of respect, how much of my (unpatented) work they're using to reshape their company. If I didn't know better I might think that someone inside the company is claiming credit for my work and doesn't want the boss to know. ";->"

I wasn't sure what this post was about so I did a little Googling and came upon a post on the atom-syntax mailing list entitled Yahoo and "Media RSS" which points out that Yahoo! has created a specification entitled "Media RSS" Specification Version .9 (DRAFT). I found it interesting that Yahoo! is throwing its weight behind a spec to replace the current mechanisms used for podcasting. I am not surprised that Dave Winer was irritated especially since some of the stuff in the spec seems extremely questionable (the media:people is a single element that can contain multiple people separated by the '|' character, attributes like playerWidth & playerHeight that are supposed to control how big the media player window used to consume content should be, etc).

However before getting deeper into the Yahoo! specification I stumbled on a post by Danny Ayers on the atom-syntax mailing list which expressed some confusion about how XML vocabularies are defined

Correct me if I'm wrong, but it looks a little broken:

<media:content url="http://www.foo.com/movie.mov"; fileSize="12216320"
    playerUrl="http://www.foo.com/player?id=1111"; playerHeight="200"
    isDefault="true" expression="full" bitrate="128" duration="185">

The attributes aren't namespace-qualified, yet aren't defined in the
RSS 2.0 spec.

Danny Ayers seems to think that the absence of a namespace name on an attribute is equivalent to the attribute being in some 'empty' namespace along with other types that are in no namespace in that vocabulary. That is actually incorrect. The best documentation to put one straight on how to consider to elements and attributes in today's age of XML namespaces is the W3C XML Schema Primer. The XML Schema recommendation is the primary specification which describes how defining XML vocabularies in a namespace aware manner is supposed to work.

An attribute with an explicit namespace name (i.e. that has a prefix) is a global attribute which belongs to a particular vocabulary. There is only one declaration of an attribute with that name (namespace URI & local name pair) in the vocabulary. On the other hand, an attribute without a namespace name is scoped locally to the element it is declared on and is only defined in the context of that element. This means in a particular vocabulary multiple definitions of an attribute with a particular name can exist if it is un-namespaced since it is scoped locally to its owner element. 

Since Danny Ayer's is the co-author of the upcoming book entitled Beginning RSS and Atom Programming  I hope he does some more research on designing XML vocabularies before the book is published. A lot of the power of RSS is the ability authors have of defining their own vocabularies as RSS modules and I'd hate to see a new generation of RSS module designers inherit a bunch of bad habits because they read the wrong stuff in a book.


Saturday, December 18, 2004 9:32:03 AM (GMT Standard Time, UTC+00:00)
Yeah, definitely. As media:content element isn't in RSS namespace, it can use whatever attributes. Probably Danny was confused by common restriction in W3C specs on using unprefixed attributes of specified elements, such as in XSLT, XInclude etc.
Saturday, December 18, 2004 10:03:58 AM (GMT Standard Time, UTC+00:00)
Well now this is somewhat strange. I stumbled across that problem lately and couldn't find a good definition in the XML NS spec (http://www.w3.org/TR/REC-xml-names/), especially on default namespaces. Thanks for clearing this up.

I still wonder about something: the default Java SAX parser does not really seem to comply with this - if you feed him this piece of XML:
&lt;footag xmlns="http://www.example.com/bar" attr="1"/&gt;
It actually reports the "attr" attribute as being in no (aka the empty) namespace.

Now reading that spec it sounds as if attr is declared locally and should by that be in the XML Namespace of footag, shouldn't it?
Saturday, December 18, 2004 4:29:44 PM (GMT Standard Time, UTC+00:00)
oop, now everything is ok. they must have kissed his ass in the mean time.

"Sometime in the last few days Yahoo announced that they were working on a new RSS 2.0 namespace that relates, somehow, to their (new?) media search capability. There's a spec and a mail list. I received no advance notice of the work, although it appears that others did. There were some substantial errors in the initial draft that will be corrected soon, according to posts from Yahoo people on the mail list. It's good that they're doing their work in a namespace, as mandated by the RSS 2.0 roadmap. I'm not sure of the purpose, but am watching the mail list. Is it a good idea? No one knows. It doesn't look like the advance from podcasting that they claim it is, but it's really hard to tell. Permanent link to this item in the archive."
Saturday, December 18, 2004 4:37:09 PM (GMT Standard Time, UTC+00:00)
>It actually reports the "attr" attribute as being in no (aka the empty) namespace.

Yes, this is what is supposed to happen as defined by the relevant specs. Some consider this a bug in the Namespaces in XML recommendation.

Unfortunately, it takes some extra knowledge about how the rest of the XML specs fit together to realize 'attr' is defined in the context of the 'footag' element in "http://www.example.com/bar" namespace. So if one was looking for the definition of what 'attr' means they are to go to the definition of the 'footag' element.
Tuesday, December 21, 2004 6:54:26 PM (GMT Standard Time, UTC+00:00)
Dare, you will note I said "Correct me if I'm wrong". From the responses I got on list and from further research I came to the conclusion that strictly speaking the Media RSS usage was (almost certainly) legal, but probably not a good idea.

I don't accept that the XML Schema specs are the primary specification on XML Namespaces, at least not in this context, as there is no dependent link. I believe you are factually incorrect on that point. But I accept your suggestion that they may be useful in determining how things are *supposed* to work...

XML Namespaces (1.0)+errata are fairly woolly on this particular point (as is the Infospace material incidentally). Your statement "Some consider this a bug in the Namespaces in XML recommendation" does suggest there is some margin for doubt.

If you'd done a little more research you'd have seen my reason for considering the no-namespace attributes to ill-advised: SAX at least gives the same value for the namespace of a no-namespaced attribute (an empty string) as a no-namespaced element. Comparisons on this could easily lead to erroneous behaviour.

I'm amused by your notion of "a new generation of RSS module designers" - there are only a couple of dozen modules designed specifically for RSS 2.0 (the RSS 1.0 and Atom base vocabularies have namespaces, so the issue doesn't arise). But I sincerely do hope I haven't included anything that might lead developers into bad habits.
Tuesday, December 21, 2004 6:58:31 PM (GMT Standard Time, UTC+00:00)
Sorry, that should have read "...a couple of dozen modules at most..." - in practice there only seem to be two or three that have any significant deployment.

Oh, and thanks for linking to the book ;-)
Wednesday, December 22, 2004 6:14:27 PM (GMT Standard Time, UTC+00:00)
I too find the Namespaces in XML spec (http://www.w3.org/TR/1999/REC-xml-names-19990114) pretty wooly on the subject of the namespace of a non-prefixed attribute. In particular, the sentence "Note that default namespaces do not apply directly to attributes" leaves one wondering how a default namespace can apply *indirectly* to attributes - which I don't think they can.

However, the example at the end of section 5.3 is pretty clear: a non-prefixed attribute is not in a namespace. If a non-prefixed attribute was in either the default namespace or the namespace of the containing element then the very last "good" element in the example would have two "a" attributes in the "http://www.w3.org" namespace which is presumably not what is intended.
Comments are closed.