Subject: Non-namespaced extension attributes

From: James M Snell <[email-masked]>
Date: Sun, 14 Oct 2007 16:30:03 -0700

Here's a question,

In Section 6.2 of RFC 4287, it says the following:

   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...  For the
   purposes of this discussion, unrecognized markup from the Atom
   vocabulary will be considered "foreign markup".

The beginning of Section 6.3 goes on to say...

   Atom Processors that encounter foreign markup in a location that is
   legal according to this specification MUST NOT stop processing or
   signal an error.

With that in mind, consider this example:

  <feed xmlns="http://www.w3.org/2005/Atom" dir="rtl">
    ...
  </feed>

The dir attribute is defined in an Internet-Draft:

  http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-04.txt

As of today, if you run a feed containing the dir attribute through the
Feed Validator today, it will throw an error complaining about the
unknown dir attribute:

This feed does not validate.

    * line 2, column 0: Unexpected dir attribute on feed element [help]

          <a:feed xmlns:a="http://www.w3.org/2005/Atom"

Because the dir attribute is defined by an I-D, Sam has agreed to change
the validator to return a warning instead of an error but this opens up
a more general question about the use and treatment of non-namespaced
extension attributes within Atom.  According the language in Section 6.2
and 6.3, such attributes are to be treated as foreign markup and
ignored.  However, doing so makes validation difficult because of the
difficultly in differentiating between a truly unknown attribute and a
misspelled one.  For instance, <link ref="via" href="foo" /> Is "ref"
actually supposed to be "rel" or is it really "ref".

Sam's position (which he can correct if I have misstated anything) is
that the validator should take a strict approach and mark all unknown,
non-namespaced attributes as an error unless there is a known
specification that is specifically updating RFC4287, as is the case with
the Bidi draft.

I wanted to see what others thought about this.  How should such
extensions be treated?  What if someone wanted to come along and invent
a new element in the atom namespace, e.g. <atom:foo />.  What should the
validator do?  Ignore it? Signal an error?

- James

---

From: Sam Ruby <[email-masked]>
Date: Sun, 14 Oct 2007 20:05:32 -0400

> validator do?  Ignore it? Signal an error?

1) You do realize that there is a [email-masked] 
mailing list, don't you.  :-)

2) Overall, the reason the feedvalidator is the way it is in this area 
is (1) to catch mispellings, and (2) to enable people who create 
internet drafts to safely create new elements and attributes without 
concern over existing usage.  Yes, it does mean that the feed validator 
needs to be updated as new drafts are published; but that's generally 
not been a problem.

3) The only reason I said warning in this case is that the I-D isn't yet 
approved, and the warning will state exactly that.  Should it become 
approved, there would be no warning.  Should it expire, the warning 
would revert back to an error.

4) James and I have had a background conversation going over a long 
period of time... he has advocated introducing additional subtleties in 
gradation, and not just limiting things to errors and warnings.  In 
general, I have found that not everybody who runs the feed validator 
against their feed is as well versed in the spec as people who tend to 
follow this (atom-syntax) mailing list are, and would be confused.  In 
such cases, simple (it either allowed by an existing spec, or it is not; 
if allowed, it either generally works interoperably or it doesn't) is 
better.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Mon, 15 Oct 2007 10:05:41 +1000

> specification that is specifically updating RFC4287, as is the case with

It's not an error, but that doesn't mean that the validator couldn't issue a
warning that the attribute is being ignored as foreign markup.

e.

---

From: James M Snell <[email-masked]>
Date: Sun, 14 Oct 2007 18:42:44 -0700

Sam Ruby wrote:
> [snip] 
> [snip]

Yes, but I felt that this was more of a spec issue than of any single
impl. Specifically, I am concerned that other implementations might get
the wrong idea by looking at how the validator acts and emulating it's
behavior with regards to unknown attributes.

> [snip] 

Or it is generally allowed by the spec but there are a number of subtle
and not-so-subtle issues that could impact interoperability.  I
understand the need for simplicity, but I think it is equally important
to educate implementors about the various subtleties inherent in the
spec. For instance, there is a common misconception that "foreign
markup" only covers stuff outside the Atom namespace; however, Section
6.2 makes it very clear that that's not the case.

- James

---

From: Sam Ruby <[email-masked]>
Date: Sun, 14 Oct 2007 23:59:10 -0400

James M Snell wrote:
> spec.

While the subtleties of a wine's bouquet are important to a proper wine 
connoisseur, they often are lost on the typical frat student.

I encourage you to either subscribe to, or simply review the recent 
posts made to, the feedvalidator-users mailing list:

   http://groups.google.com/group/feedvalidator-users

The message that will be produced when dir attributes are encountered 
will simply state that this attribute is defined by a draft document and 
is therefore subject to change.  Not very subtle, but effective... 
wouldn't you agree?

A dir attribute with a value of "upside down" will summarily be flagged 
as an error.  Again, not very subtle, but it will have the desired 
result, and will enable future I-D's to define new values without 
worrying about adversely affecting existing client's behavior.  I will 
also note that such values are not allowed by the non-normative RELAX NG 
Compact schema either.

- Sam Ruby

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 15 Oct 2007 11:24:13 +0200

> validator do?  Ignore it? Signal an error?

Section 6.3 defines error-recovery, it does not mean however that
"unrecognized markup from the Atom vocabulary" is not an error.
Validators should throw an error for those attributes and elements
"from the Atom vocabulary" that hasn't been defined in RFC4287 or
another I-D.
I don't know what the current behavior is, but I think the
feedvalidator (or any other Atom validator, if any) should also signal
warnings for non-Atom-namespaced markup (markup from other
vocabularies) that are not "known extensions" (iTunes, GeoRSS, etc.)

IMO, validators should, in addition, link to the specs of the
extensions used by the feed. For instance (once the dir= I-D is
approved), it shouldn't throw an error or signal a warning when the
dir= attribute is (correctly) used, but it could say "this feed uses
the RFCxxxx extension" with the appropriate link.

-- 
Thomas Broyer

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 15 Oct 2007 23:42:36 +0700

Thomas Broyer wrote:
> > extensions be treated?  What if someone wanted to come along and 
> > invent a new element in the atom namespace, e.g. <atom:foo 
> />.  What 
> > should the validator do?  Ignore it? Signal an error?

I wrote a validator that can be put between an APP client and APP server to ensure that they are both complying with the spec when exchanging entries. It just short-circuits the communication at the first error detected, like an XML parser does. I provide no distinction between unrecoverable errors, recoverable errors, or warnings. I have chosen to allow any atom element to have any extra attributes, in any namespace (including the empty namespace), since that seems to be the intention of section 6.2 of RFC4287. 

> Section 6.3 defines error-recovery, it does not mean however 
> that "unrecognized markup from the Atom vocabulary" is not an error.

In 6.4, it says "Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden." So, even foreign markup in atom:id, and atom:updated is allowed, in spite of the Relax NG schema.

> Validators should throw an error for those attributes and 
> elements "from the Atom vocabulary" that hasn't been defined 
> in RFC4287 or another I-D.

The specification does not say validators should throw an error. It really doesn't explicitly state what processors should do. But, I think that 6.2's strongly suggests that markup that is not understood should be allowed, because it might be defined in an update of RFC4287.

- Brian

---

From: Bill de hOra <[email-masked]>
Date: Tue, 16 Oct 2007 02:13:40 +0100

James M Snell wrote:

> extension attributes within Atom.  

I don't understand how this can ever be a validation error. Atom doesn't 
disallow them, XML doesn't disallow them.

(the point made later about the RNC disallowing non-namespaced 
attributes is neither here not there)

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Mon, 15 Oct 2007 21:41:57 -0400

> attributes is neither here not there)

*sigh*

Let me start at the beginning.  How many validation errors should there 
be in the following document?

<?xml version="1.0" encoding="utf-8"?>
<Feed xmlns="http://www.w3.org/2005/Atom">

   <title>Example Feed</title>
   <link href="http://example.org/"/>
   <updated>2003-12-13T18:30:02Z</updated>
   <author>
     <name>John Doe</name>
   </author>
   <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

   <entry>
     <title>Atom-Powered Robots Run Amok</title>
     <link href="http://example.org/2003/12/13/atom03"/>
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
     <updated>2003-12-13T18:30:02Z</updated>
     <summary>Some text.</summary>
   </entry>

</Feed>

- Sam Ruby

---

From: Bill de hOra <[email-masked]>
Date: Tue, 16 Oct 2007 15:23:34 +0100

Sam Ruby wrote:

> [...]

Just explain why it's a validation error; can you do that?

cheers
Bill