The normative English spec text on this in RFC 4278 is not clear. The Relax NG non-normative grammar definitively forbids atom-namespaced elements from appearing anywhere except where RFC 4278 explicitly allows them, and the W3C validator at least follows the RNG grammar and treats this as a hard error. I think this is an error in the grammar but the English text is, of course, ambiguous.
One place where this would be useful would be to place an atom:link underneath an atom:author element, as part of an extension that does not need to define its own link element, but can re-use the Atom one. A very specific, interesting, and useful case here would be <author><link rel="alternate" type="application/poco+xml" href="..." />...</author>. The expectation would be of course that clients that don't understand this type of link inside an <author> must ignore them. Here's a trivial test case; the W3C's Feed Validator at http://validator.w3.org/feed/check.cgi flags the link as an 'unknown element': <?xml version='1.0' encoding='UTF-8'?> <entry xmlns='http://www.w3.org/2005/Atom'> <author> <name>Joe</name> <link rel="alternate" href="http://example.org"; /> </author> <title> </title> <updated>2009-11-23T09:50:40.239-08:00</updated> <id>tag:example.com,1999:383838383</id> <content> </content> </entry> The non-normative Relax NG grammar in RFC 4287 explicitly forbids the use of atom:link here because it excludes anything in the atom namespace from being extension elements, e.g.: simpleExtensionElement = element * - atom:* { text } and so forth. On the other hand the normative text of the specification doesn't explicitly say this; it says that (basically) extension elements are anything that is "foreign markup", and that's allowed anywhere. Looking at the definition of "foreign markup", it says: 6.2. Extensions to the Atom Vocabulary The Atom namespace is reserved for future forward-compatible revisions of Atom. Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. For the purposes of this discussion, unrecognized markup from the Atom vocabulary will be considered "foreign markup". My reading of this is that if atom:link _in the context of atom:author_ is "foreign markup" then it's allowed, otherwise it's not allowed. I believe the intent is to allow it, because of the first few sentences of 6.2 above. If it is forbidden, then future versions of Atom could not ever allow atom:link in atom:author without breaking backwards compatibility. Meaning that this decision was frozen at 1.0 and could never be revised -- which would be odd, and I don't remember us making that decision :). Against my interpretation is the idea that this probably represents an error in the feed, and so treating this as foreign markup would reduce the ability to do error checking. On the third hand, there is very little useful that can be done with such an error in real use other than ignore it, which is what I suspect that real processors (not validators) do. I think it's a useful and obvious mechanism for extending Atom. Thoughts? -John Panzer
