Subject: extension elements inside link elements?

From: Eric Scheid <[email-masked]>
Date: Tue, 24 May 2005 18:22:29 +1000

> 4.2.9 The "atom:link" Element
> 
> The "atom:link" element is an empty element that defines a reference from an
> entry or feed to a Web resource.

did we want to prevent expressions like this:

    <link href=".." type=".." rel=".." title="..">
        <ext:foo .../>
    </link>

e.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 May 2005 07:55:30 -0700

>     <link href=".." type=".." rel=".." title="..">

I read "empty" as "always empty", so the XML novice in me would say 
that the above expression in inherently wrong.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Tue, 24 May 2005 11:07:01 -0400

> that the above expression in inherently wrong.

4.2.9 (editorial):  The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove "is an empty element that".

http://www.imc.org/atom-syntax/mail-archive/msg14365.html

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 17:26:39 +0100

> Remove "is an empty element that".

That's not an editorial change, that's newly allowing extension  
elements in a place most people (such as Paul and myself) assumed  
they weren't.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 24 May 2005 12:39:38 -0400

> That's not an editorial change, that's newly allowing extension

Fully disagree. The extensibility sectin is quite clear.

> elements in a place most people (such as Paul and myself) assumed

I don't know anything about "most people" and neither do you. Paul
stated the meaning of the text of in question, no his own thoughts on
the matter.

Why don't you work on the problems in the draft instead of dwelling on
this tiny nitpick?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Tue, 24 May 2005 12:44:11 -0400

On 5/24/05, Graham <[email-masked]> wrote:
> That's not an editorial change

FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html

"But if I encounter a <link> element that's weirdly non-empty and
contains markup from some other namespace, that's the kind of
situation you're talking about. I think it would be OK to leave
behavior undefined as you say."

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 18:43:49 +0100

> behavior undefined as you say."

I'm not sure I object to it in principle, though I think it's a weird  
place for someone to put extentsions, but I object to it being  
characterised as an editorial change.

I also think removing that piece of text makes it unclear that the  
element is normally empty.

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 24 May 2005 19:59:32 +0200

Graham wrote:

> place for someone to put extentsions,

What about the following extension?
<atom:link href="http://example.com/some/negociated/content">
   <ext:media-type>image/svg+xml</ext:media-type>
   <ext:media-type q="0.5">image/png</ext:media-type>
   <ext:media-type q="0.2">image/jpeg</ext:media-type>
</atom:link>

> element is normally empty.

What about:

    The "atom:link" element defines a reference from an entry or feed to
    a Web resource. Atom doesn't define any child to the "atom:link",
    though it might contain extension markup.

-- 
Thomas Broyer

---

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

> Subject: Re: extension elements inside link elements?

> e.

Whether the draft allowed it or not, atom:link isn't an extension
point. That would be Section 6.3 style "unknown foreign markup".

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 24 May 2005 20:50:13 +0200

David Powell wrote:

>point.
Could you explain why?

-- 
Thomas Broyer

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 20:24:16 +0100

> point. That would be Section 6.3 style "unknown foreign markup".

Unless there's a memo I missed, extensions are a subset of "unknown  
foreign markup".

Graham

---

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

> Unless there's a memo I missed, extensions are a subset of "unknown

That is what I said isn't it?  Some "unknown foreign markup" is an
extension.

-- 
Dave

---

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

>>Whether the draft allowed it or not, atom:link isn't an extension

The following are extension points:

* Adding additional metadata to atom:feed by using Section 6.4
Extension Elements.

* Adding additional metadata to atom:entry by using Section 6.4
Extension Elements.

* Adding additional metadata to Person Constructs by using Section 6.4
Extension Elements.

* Adding new atom:link types by using new @rel attributes.

* Embedding arbitrary data by using atom:content.

Atom processors won't fail if you put elements in other places, but I
didn't think that they were extension points.

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Tue, 24 May 2005 13:28:09 -0700

> elements in a place most people (such as Paul and myself) assumed  

On the one hand I agree with Graham; this does feel like a  
substantial change.  On the other, it's hard to see that having stuff  
inside <link> would do any damage; I best most software would never  
notice it.  Having said that, I don't agree that it's editorial  
change and I'd like to see a couple more voices in favor and give  
people a chance to shout "No!" before going ahead and doing it. -Tim

---

From: Tim Bray <[email-masked]>
Date: Tue, 24 May 2005 13:29:30 -0700

> element is normally empty.

+1 -Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 24 May 2005 13:54:43 -0400

> characterised as an editorial change.

Well, that's how the reviewer felt, and I though it was a super minor
change. Also, I observe that more than 3 or 4 WG members have
expressed a desire to extend it that way. I can't think of a problem
with that, though I would surely ignore them when processing a link
element.

> element is normally empty.

I don't think so. There's an example just below, in 4.2.9.2. We could
show some more examples. The other element with no defined content is
atom:category. Its RNC illustration also shows it as empty, but the
text doesn't call it an "empty element."

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 25 May 2005 02:29:50 +0200

* Thomas Broyer <[email-masked]> [2005-05-24 20:10]:
> What about:
> 
>    The "atom:link" element defines a reference from an entry or
>    feed to a Web resource. Atom doesn't define any child to the
>    "atom:link", though it might contain extension markup.

I may be trying to pick a colour for the bikeshed, but is an
explicit mention of the possibility of extension elements really
necessary? Unnecessary redundancy is an invitation for
inconsistencies.

Regards,
-- 
Aristotle

---

From: David Powell <[email-masked]>
Date: Wed, 25 May 2005 21:40:54 +0100

> people a chance to shout "No!" before going ahead and doing it. -Tim

I'm either +1 or -1.  I haven't decided yet, but I'm lying in the road
on this one :)  I can't answer this until something is explained to
me:

        What is section 6.3 "unknown foreign markup" for?

* We have content constructs which are extensible by allowing any type
of data to be embedded using the IANA registry of MIME types.

* We have carefully designed an IANA registry for @rel values, and used
the distributed nature of namespace URIs to allow for unregistered
values.

* We have carefully defined two classes of extension construct (Simple
and Structured) to ensure that extensions are disambiguated by
namespace URIs, and that xml:lang issues are considered. Simple
extensions make generic support for this class of extension feasible
for real-world implementations; Structured extensions are there for
those that need the extra power.

And, we have "unknown foreign markup".

I believed that the purpose of "unknown foreign markup" was to define
an error handling strategy for parsers, and to give the spec a bit of
breathing room for things like Atom 1.1.  This is great.

But I'm getting a sneaking suspicion though, that "unknown foreign
markup" is positioning itself as a third (poorly thought through)
class of extension point.

Please tell me that that isn't the intent?

In the future someone said:

> Hey, I've had an idea for an extension to atom:link.  The text content
> of atom:link could be a tooltip giving a long description for the link
> It would work like this:
> 
> <atom:link rel="alternate" href="http://example.com/dave">
>   This is a picture of my holiday.  I'm the one on the right.
> </atom:link>
> 
> What do you think?

In the future someone said:

> Hey, I've had an idea for an extension to atom:link.  The text content
> of atom:link could be a GUID of an ActiveX control that is capable of
> displaying the linked object.  It would work like this:
> 
> <atom:link rel="alternate" href="http://example.com/dave">
>   0A28AB31-3143-4b70-B969-8650BDFDBAC9
> </atom:link>
> 
> What do you think?

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Wed, 25 May 2005 14:04:52 -0700

>         What is section 6.3 "unknown foreign markup" for?

I think the notion of foreign markup exists so that we can write the  
extremely-important section 6.3, our MustIgnore assertion.  The point  
is, either software knows what to do with an extension and does it,  
or if not it's not allowed to to break and should pass text through  
in contentful contexts. -Tim

---

From: David Powell <[email-masked]>
Date: Wed, 25 May 2005 22:29:12 +0100

> extremely-important section 6.3, our MustIgnore assertion.

Sorry I wasn't clear:

When I said "Section 6.3" markup, I was referring to the subset of
"Section 6.3 markup" that isn't also a "Section 6.4 extension". (we
could do with a term for this)

Section 6.4 extensions are MustIgnore, so what is this other subset of
6.3 markup for? I know that it the intent is that Atom parsers
shouldn't fail on it, but is it supposed to be an extension point for
extension authors?

The problem with section 6 is that we define 3 different classes of
non-Atom markup, but don't say why we've done that, or help authors to
know which type they should choose when they write a document.

I'll have a go at writing an editorial proposal to explain things a
bit better.

It doesn't really make sense we have thought out how to extend
atom:feed, atom:entry, atom:author etc, but atom:link is a sub-RSS
free-for-all.

-- 
Dave

---

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

> in contentful contexts. -Tim

Basically, I want future versions of Atom to be able to add markup
anywhere it likes (including on or inside atom:link), and Atom 1.0
should be designed to ignore such "unknown foreign markup".

What I really don't want is "unknown foreign markup" to be used as a
poor-man's "Extension Element".

Does that match the consensus of the WG?

I'm also a bit confused about the terminology in Section 6.3:

> It might be the case that the software is able to process the
> foreign markup correctly and does so. Otherwise, such markup is
> termed "unknown foreign markup".

So "unknown foreign markup" is "foreign markup" that software is
unable to process? But then 6.3 goes on to explain how to process it.
This sounds like a contradiction?

Also, in what cases would software be able to process "foreign markup"
other than by ignoring it as described in section 6.3 or treating it
as a 6.4 extension?

So I don't see how the term "foreign markup" and "unknown foreign
markup" are any different?

Also, if 6.4 extensions are a subset of "unknown[?] foreign markup",
then the rule "[software] MUST NOT change its behavior as a result of
the markup's presence" doesn't really make sense? Surely extensions
can change the behaviour of software.

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 26 May 2005 20:20:23 +0200

David Powell wrote:

>unable to process?
Yes, something in a namespace that is not understood by the Atom Processor.

>But then 6.3 goes on to explain how to process it.
No, why?

Say I am an Atom Processor and I find these extensions elements:
<!-- defined before: 
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" -->
<geo:lat>26.58</geo:lat>
<geo:long>-97.83</geo:long>

Is this something I know how to process?

    * yes: this is "known foreign markup", I process it
    * no: this is "unknown foreign markup", I ignore it without failing
      or signaling an error

>other than by ignoring it as described in section 6.3 or treating it
Treating it as a 6.4 extension *is* processing it as described in 
section 6.3.
There is no other case (this is technically implied by section 6.4, see 
below)

>markup" are any different?
"unknown foreign markup" is the subset of "foreign markup" that an Atom 
Processor ignores because it doesn't know what do do with it (i.e. how 
to process it).

>Also, if 6.4 extensions are a subset of "unknown[?] foreign markup",
6.4 extensions are not a subset of "foreign markup" or "unknown foreign 
markup". 6.4 extensions are the whole "foreign markup" set (except it 
doesn't deal with "foreign attributes", but the whole section 6 and the 
whole spec doesn't deal with them).

If you read carefully the section 6.4, you'll notice that what is not a 
Simple Extension Element is a Structured Extension Element.
A Simple Extension Element is an element with no attribute and is either 
empty or has text-only content.
A Structured Extension Element is an element with at least an attribute 
or a child.

These are Simple Extension Elements:
<my:ext/>
<my:ext></my:ext>
<my:ext>foo</my:ext>

These are Structured Extension Elements:
<my:ext attr="val" />
<my:ext attr="val"></my:ext>
<my:ext attr="val">foo</my:ext>
<my:ext attr="val"><foo:bar/></my:ext>
<my:ext attr="val">baz<foo:bar/>baz</my:ext>
<my:ext><foo:bar/></my:ext>
<my:ext>baz<foo:bar/>baz</my:ext>

Is there any other construct I missed?

-- 
Thomas Broyer

---

From: David Powell <[email-masked]>
Date: Thu, 26 May 2005 19:52:49 +0100

>>This sounds like a contradiction?

Ok, I'd interpreted "ignoring" it to be processing it, as opposed to
failing.  I'll concede that I misinterpreted that.

>     * no: this is "unknown foreign markup", I ignore it without failing

So known 6.4 extensions are "known foreign markup", and unknown
extensions are "unknown foreign markup"?  Ok.

> markup". 6.4 extensions are the whole "foreign markup" set

6.2 says that new elements and attributes can be added. Earlier
discussion in this thread suggested that these may be inside
<atom:link> elements. Isn't this a type of markup that isn't a 6.4
extension?

6.4 extensions can only appear in atom:feed, atom:entry, and Person
constructs. [BUG ALERT!!!! - they should blatantly be allowed inside
atom:source too, and the inheritance needs explaining]

For the people who were proposing that atom:link shouldn't ban
content, can they tell me which type of Section 6 markup they regard
it to be?  Or were they proposing that Section 6.4 should be extended
to allow Link Extensions.

> (except it doesn't deal with "foreign attributes", but the whole
> section 6 and the whole spec doesn't deal with them).

Yes it does, section 6.2 says that future versions of Atom can add new
attributes.

> A Structured Extension Element is an element with at least an attribute

Yep, I understand Section 6.4, but these rules only apply directly
inside atom:entry, atom:feed, and Person constructs [and atom:source].
Foreign markup in other places isn't 6.4 markup, so what is it?

> Is there any other construct I missed?

* Elements in places that they aren't banned such as atom:category, and
depending on the outcome of this thread, atom:link - presumably
intended for future versions of Atom.  Allowed by Section 6.2.

[BUG ALERT!!! The RNG says that the content is empty, the text
doesn't]

* Attributes on any existing elements.  Allowed by Section 6.2.

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 26 May 2005 21:50:04 +0200

>extensions are "unknown foreign markup"?  Ok.
Yes, though "known foreign markup" is not used in the spec (or I missed it).
And actually, you're right (see below) saying 6.4 extensions do not 
describe the whole "foreign markup" set (see below).

>6.2 says that new elements and attributes can be added.
>
6.2 deals with the "Atom vocabulary", which is the markup in the Atom 
namespace or un prefixed attributes on Atom-namespaced elements (this is 
my interpretation, it's not clearly stated in the spec, and I'm quite 
sure I already raised this in the past two weeks).
6.1 deals with "foreign markup", that is (still not clearly stated by 
the spec text) markup in a namespace different from the Atom namespace.

>Earlier
You're right, 6.4 extensions are the subset of "foreign markup" known as 
"Metadata Elements", they' do not represent the whole "foreign markup" set.

>to allow Link Extensions.
If future versions of Atom adds (unprefixed) attributes or 
(Atom-namespaced) elements inside atom:link, they will be "Extensions to 
the Atom Vocabulary" per section 6.2.

If someone defines extensions (attributes or elements in a namespace 
other than the Atom namespace) inside atom:link, they will be 
"Extensions From Non-Atom Vocabularies", per section 6.1. As they won't 
match section 6.4 criteria (not inside atom:feed, atom:entry or a Person 
Construct), they won't be "Metadata Elements" and thus their role is 
undefined (per section 6.4, last sentence of the single 6.4 paragraph).

>Yes it does, section 6.2 says that future versions of Atom can add new
You're right. Although you should have refered to section 6.1. Their 
role is just undefined by the spec.

>Foreign markup in other places isn't 6.4 markup, so what is it?
It is just "foreign markup", per section 6.1. Its role is undefined by 
the spec. What the spec says is only how to process it (the MustIgnore 
in section 6.3).

Markup which the section 6.2 deals with is markup inside the Atom 
namespace. It is not "foreign markup", though it must be considered as 
such by Atom 1.0 Processors for the "purposes of this discussion". If it 
matches 6.4 criteria, it is "Metadata Elements" markup, otherwise, it is 
just "Atom markup which is considered foreign markup for the purposes of 
this discussion".

I must however agree that the spec is not as clear as it could be... it 
doesn't for example clearly define "Atom Vocabulary" on which definition 
of "foreign markup" is relying.

-- 
Thomas Broyer

---

From: David Powell <[email-masked]>
Date: Thu, 26 May 2005 21:33:30 +0100

> sure I already raised this in the past two weeks).

Yes, I proposed that we fix this here too:
<http://www.imc.org/atom-syntax/mail-archive/msg15743.html>

It is extremely important that clients can discriminate Section 6.2
elements from Section 6.4 elements.

If we don't make this change, then implementations could interpret
atom-namespaced "section 6.2 elements" inside entry/feed/person/source
as "section 6.4 metadata elements". Implementations may then forward
these elements believing that they are harmless metadata, when in fact
they are more likely to be control elements, which they definitely
should not be forwarded by implementations that don't understand them.

This is pretty much exactly the same problem as the one that caused
HTTP 1.0 Persistent Connections to fail. [see RFC2068 section 19.7.1]

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 27 May 2005 00:16:05 +0200

><http://www.imc.org/atom-syntax/mail-archive/msg15743.html>
It'd be still be necessary to define the term "vocabulary" somewhere, in 
section 6 or in the introduction (section 1).

As "vocabulary" is only used only in sections 6.1 and 6.2, I suggest 
using "namespace" instead:

[
6.1  Extensions From Non-Atom Namespaces

   This specification describes Atom's XML markup namespace.  Markup
   from other namespaces ("foreign markup") can be used in an Atom
   document.  Note that the atom:content element is designed to support
   the inclusion of arbitrary foreign markup.

6.2  Extensions To The Atom Namespace

   Future versions of this specification could add new elements and
   attributes to the Atom markup namespace.  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 namespace will be
   considered "foreign markup".
]

This however doesn't prevent us adding your sentence to 6.4 to make it 
clearer.

-- 
Thomas Broyer

---

From: David Powell <[email-masked]>
Date: Fri, 27 May 2005 00:21:12 +0100

>>Thursday, May 26, 2005, 8:50:04 PM, Thomas Broyer wrote:
>>

>    considered "foreign markup".

This sounds good, but 6.2 ought to also include unprefixed attributes
on atom elements as well as atom: prefixed ones.

> This however doesn't prevent us adding your sentence to 6.4 to make it

I think 6.3 would be much easier to understand if its position was
swapped with 6.4. When you read 6.3 you assume that everything not
mentioned so far must be "unknown foreign markup", then when you read
6.4, it redefines some of that as "metadata elements". They are
intended to be disjoint, but the ordering suggested to me that 6.4 was
a subset.

Paragraph 2 of 6.3 reinforced my misconception that 6.4 markup is
subset of "unknown foreign markup", especially as it didn't mention
markup on other elements or attributes as 6.2 proposed. If 6.3 and 6.4
were swapped, then I think paragraph 2 of 6.3 could be trimmed down to
avoid this. Replace paragraph 2 & 3 of 6.3, with:

  When unknown foreign markup is encountered in a Text Contruct or
  atom:content element, software SHOULD ignore the markup and process
  any text content of foreign elements as though the surrounding
  markup were not present.

  When unknown foreign markup is encountered elsewhere, software MAY
  bypass the markup and any textual content and MUST NOT change its
  behavior as a result of the markup's presence.

--
Dave

---

From: David Powell <[email-masked]>
Date: Sat, 28 May 2005 09:52:30 +0100

> elements in a place most people (such as Paul and myself) assumed  

IF, the interpretation of Section 6, that Thomas Broyer has helped me
to hammered out is correct, then:

Extension Elements [6.4], in Atom 1.0, are allowed only as direct
children of atom:entry, atom:feed, Person Constructs, and atom:source.
They must be qualified with a namespace, and it mustn't be the atom
namespace. Extension Elements, atom:content, and atom:link/@rel are
the only User Extensions to Atom.

Future versions of Atom [6.2] may add additional elements to the Atom
namespace, may add attributes (namespaced or otherwise) to existing
Atom elements, and presumably may allow text inside Atom elements
(basically any markup that isn't in the spec or an Extension Element).
(Text as a 6.2 element isn't mentioned, but it probably ought to be
treated as 6.2 by clients.)

This is to allow Atom 1.0 implementations to be forward compatible
with future versions of Atom. Atom 1.0 implementations won't know how
to handle these elements and MUST ignore them, and MUST NOT forward
them. (they could be some sort of link-level control element; or they
might be an element that allows a relative URIRef, which would break
if it was dependant on the source document's base URI)

So, assuming that that description is roughly correct, and that we can
rework section 6 to make it easier to understand and unambiguous about
the difference between 6.2 and 6.4 markup, then I am +1 to removing
"is an empty element that", because it contradicts section 6.2 which
is supposed to apply everywhere.

-- 
Dave

---

From: Thomas Broyer <[email-masked]>
Date: Sat, 28 May 2005 13:04:23 +0200

David Powell wrote:

>namespace.
Note that this kind of extension elements ("foreign markup" appearing in 
atom:feed, atom:entry, Person Constructs, and atom:source) is called 
Metadata Elements, because Atom states such extensions provide 
additional metadata to their container element (or more accurately 
additional metadata to the to the resource represented by the container 
element).

>Extension Elements, atom:content, and atom:link/@rel are the only User Extensions to Atom.
>  
>
No (for the definition of Extension Elements you gave above).

Atom allows foreign markup anywhere in an Atom document. Foreign markup 
is made of "extension elements" and "extension attributes" (i.e. 
anything not in the Atom namespace, except unprefixed attributes on 
Atom-namespaced elements). Atom doesn't define the role/interpretation 
of foreign markup except for those elements appearing in atom:feed, 
atom:entry, Person Constructs and atom:source, which it defines as 
Metadata Elements carrying additional metadata about their container 
element.

>Atom elements,
If attributes are namespaced and the namespace is not the Atom 
namespace, they obviously are "foreign attributes" (at least for me).

>and presumably may allow text inside Atom elements (basically any markup that isn't in the spec or an Extension Element). (Text as a 6.2 element isn't mentioned, but it probably ought to be treated as 6.2 by clients.)
>  
>
I think that later allowing "just text" inside an Atom element would 
prove a design flaw...

At least, it should be made clear that an Atom 1.0 Processor MUST ignore 
text as a child of an element which Atom doesn't define as allowing 
text. (er, am I clear?)

-- 
Thomas Broyer