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

From: John Panzer <[email-masked]>
Date: Sun, 29 Nov 2009 13:24:40 -0800

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

---

From: Peter Keane <[email-masked]>
Date: Sun, 29 Nov 2009 17:54:45 -0600

On Sun, Nov 29, 2009 at 3:24 PM, John Panzer <[email-masked]> 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.
>
> 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
>       }
>
> 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