On Sun, Nov 29, 2009 at 3:24 PM, John Panzer <[email protected]> wrote:
> 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? > There have been a number of interesting threads on this (I can dig up links if you'd like), but esp. regarding an atom:link child of atom:category AND atom:category as a child of atom:link. I agree it is a useful and obvious mechanism for extending Atom, but one which is unlikely to be supported by a generic atom feed consumer (if such a thing does, indeed, exist ;-)). I don't think there is a general consensus at this point pro or con, but it certainly has not caught on. I've always regarded it as offering a lightweight bridge between RDF and atom -- it seems to me quite easy to extract the "triples" suggested by these sorts of extensions (and, likewise, could it make it much easier (in many cases) to express RDF as atom. --peter > > -John Panzer > >
