Tim, Just to be clear, when I say that link should have been extensible, I mean that link should have used extensionElement* rather than undefinedContent. In fact, to be completely honest, I don't think undefinedContent should have been in the spec at all. atom:link and atom:category are the only two elements that use it, and there does not appear to be any rationale given as to why.
With that said, the real question here is not whether namespaced attributes and elements can or can not appear on the atom:link element. As you point out, and as I've mentioned in the past, the spec is very clear on this point. At issue is whether or not authors of standardized extensions should extend elements with undefinedContent when we know full well that there are API implementations out there that have made the extremely shortsighted decision to completely ignore such content. - James p.s. I wonder how many folks realize that the following examples are perfectly legal and valid according to the spec. <link href="http://example.org/foo";>This is some text</link> <link href="http://example.org/foo> <b xmlns="http://www.w3.org/1999/xhtml";>Foo!</b> </link> <category term="foo"> This entry belongs to category <xhtml:a href="/blog/categories/foo">foo</xhtml:a>! </category> Tim Bray wrote: > > On May 4, 2006, at 3:43 PM, Thomas Broyer wrote: > >> Things would have been far easier if either a) atom:link were >> extensible > > This assertion that atom:link is not extensible is simply, flatly, > completely, wrong. I just went and reviewed 4287 and I think it is > perfectly clear on this. I suggest that interested parties review > sections 4.2.7, 6.3, and 6.4 and, if they still think there is any > problem with child elements of <atom:link>, find language in the RFC > which says something other than what those sections say. -Tim > >
