Re: Can atom-namespaced elements be allowed as foreign markup?

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Sun, Nov 29, 2009 at 3:24 PM, John Panzer <jpanzer@xxxxxxx> 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="" href="http://example.org" style="color: rgb(7, 77, 143);" target="_blank">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