Subject: Comments about Extensions (1)

From: David Powell <[email-masked]>
Date: Tue, 24 May 2005 20:19:57 +0100

Section 6.4:

The RNGs in this section require Extension Elements to be in a
namespace that isn't the Atom namespace. This requirement is missing
from the text.

Proposal
--------

Add to section 6.4.1:

> A Simple Extension Element MUST be namespace-qualified. The element
> MUST be defined outside of the Atom namespace.

Add to section 6.4.2:

> The root element of a Structured Extension element MUST be
> namespace-qualified. The element MUST be defined outside of the Atom
> namespace.

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 24 May 2005 23:41:48 +0200

>namespace that isn't the Atom namespace. This requirement is missing

It's actually worse than just that.

Section 6.1 defines "foreign markup" as being "markup from other 
vocabularies". WRT section 6.2 describing "extensions to the Atom 
vocabulary", I understand this definition of "foreign markup" as "markup 
in a namespace different from the Atom one.

Section 6.4 *implies* Extension Elements are foreign markup as the first 
sentence of that section is "Atom allows foreign markup anywhere in an 
Atom document" though it's not explicit at all.

Having re-read the draft without looking at the RNC excerpts, the whole 
section 6 with its subsections are totally unclear about what is 
"foreign markup" (or what is behind "Atom vocabulary"), what are 
"extensions", what are Simple/Structured Extension Elements and how they 
relate to foreign markup.

Even more, I'm wondering why would there be a need to define 
Simple/Structured Extension Elements in terms of "constraints". I 
suppose that it's a way to distinguish extensions in the form 
<my:extension>text-only</my:extension> from extensions using attributes 
and/or child elements; and such a distinction is only necessary because 
we want to provide a hint about how to interpret extensions in the 
former form (no attribute, text-only content).
Wouldn't it be clearer (less obscure) to anyone dropping section 6.4 and 
just saying something like the following:

    Elements from foreign markup with no attribute and text-only content
    MAY be interpreted by an Atom Processor as a property (or name/value
    pair) of the parent element that encloses it. This specification
    does not provide an interpretation for other elements.

Still about extensions, have I missed something or nowhere the spec 
allows for "extension attributes" (I mean namespaced attributes 
appearing on Atom elements)? I suggest such attributes to be interpreted 
as a property (or name/value pair) of the element on which it appears.

Finally, in section 6.2, in the last sentence, "for the purpose of this 
discussion" applies only to the section 6.3 about how to process them: 
they obviously aren't "extensions", are they? I suggest moving this 
sentence into section 6.3.

There might be other things I missed this evening...

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Tue, 24 May 2005 17:59:34 -0400

> It's actually worse than just that.

Actually, I don't see a problem here. You just don't understand that
some extension content has its role defined by the spec ahead of time,
and some doesn't ("undefined"). I don't see any reason to revisit
this.

bye,

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Thu, 26 May 2005 00:23:37 +0100

> namespace that isn't the Atom namespace. This requirement is missing

Just a note:

This proposal doesn't rehash the
"extensions -- Atom NS and unprefixed attributes" thread [1], because it
only applies to "6.4 Extension Elements"; not to "6.2 future
extensions to atom" - so the arguments about change control of the
specification are irrelevant.

Is this just an editorial fix on the basis that it is already in the
RNG, and 6.4.1 already implies the presence of a namespace URI; or do
I need to campaign for consensus on this?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15035.html

-- 
Dave