Subject: Re: Confused about extensibility

From: Robert Sayre <[email-masked]>
Date: Mon, 21 Mar 2005 16:04:11 -0500

Norman Walsh wrote:
> I'm not sure the -06 draft tells a consistent story about
> extensibility.

It doesn't.

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

> 
> That last paragraph suggests that foreign markup *not* from the Atom
> vocabulary may not appear at any location, that it must only appear in
> specified places.

Correct.

> But
> 
> | 6.4  Extension Elements
> | 
> |    Atom allows foreign markup anywhere in an Atom document.
> 
> Then we're told foreign markup is allowed anywhere. Do we really mean
> that?

I think we do. Do we really want to *outlaw* the following?

<link href="..." my:ext="foo" />

> 
> The text in 4.1.2 seems related to me:
> 
> | 4.1.2  The "atom:entry" Element
> | 
> |    The "atom:entry" element represents an individual entry, acting as a
> |    container for metadata and data associated with the entry.  This
> |    element can appear as a child of the atom:feed element, or it can
> |    appear as the document (i.e., top-level) element of a standalone Atom
> |    Entry Document.
> | 
> |    The atom:entry element MAY contain any namespace-qualified
> |    [W3C.REC-xml-names-19990114] elements as children.  This
> |    specification assigns no significance to the order of appearance of
> |    the child elements of atom:entry.
> 
> Saying that atom:entry may contain namespace-qualified elements as children
> really looks out of place. If we say it here, why don't we say it for
> atom:feed and other places? I think that sentence should be deleted.

Agree.

> 
> Assuming that we *don't* mean for extension elements to appear *anywhere*,
> then were do we want them?
> 
> I think we want them:
> 
> 1. In atom:feed metadata
> 2. In atom:entry metadata
> 3. In PersonConstructs
> 

I think we want to define their role in those locations.

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Mon, 21 Mar 2005 15:51:52 -0500

| 6.2  Extensions To the Atom Vocabulary
| 
|    Future versions of this specification may 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".
| 
|    Unlike markup from other vocabularies, foreign markup from the Atom
|    vocabulary MAY appear at any location in an Atom document.

But

| 6.4  Extension Elements
| 

I think we want them:

1. In atom:feed metadata

Should they also be allowed *between* atom:entry elements in a feed?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 21 Mar 2005 23:49:07 +0100

> I'm not sure the -06 draft tells a consistent story about
[...]
> Should they also be allowed *between* atom:entry elements in a feed?

As the spec uses "interleave" content models, I think they are/will... 
though I wonder why interlaced content models are used instead of 
"ordered" content models... that would also allow DTD or XML Schema (or 
any other schema requiring deterministic content models) to be used to 
validate Atom documents...

-- 
Thomas Broyer

---

From: Norman Walsh <[email-masked]>
Date: Mon, 21 Mar 2005 18:37:14 -0500

/ Thomas Broyer <[email-masked]> was heard to say:
| Norman Walsh wrote:
|> I'm not sure the -06 draft tells a consistent story about
|> extensibility.
| [...]
|> Should they also be allowed *between* atom:entry elements in a feed?
|
| As the spec uses "interleave" content models, I think they are/will...

In the -06 draft, a feed is an interleave of metadata elements followed
by a sequence of 0 or more atom:entry elements.

| though I wonder why interlaced content models are used instead of
| "ordered" content models... that would also allow DTD or XML Schema
| (or any other schema requiring deterministic content models) to be
| used to validate Atom documents...

Because the spec says they aren't ordered.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Where it is permissible both to die and
http://nwalsh.com/            | not to die, it is an abuse of valour to
                              | die.-- Mencius

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 22 Mar 2005 09:10:50 +0100 (CET)

> by a sequence of 0 or more atom:entry elements.

Hmm, right, sorry...

> | though I wonder why interlaced content models are used instead of |
> "ordered" content models... that would also allow DTD or XML Schema |
> (or any other schema requiring deterministic content models) to be |
> used to validate Atom documents...
>

Well, by "ordered", I actually meant "non-interleaved", e.g. having a
deterministic content model...

-- 
Thomas Broyer

---

From: Robert Sayre <[email-masked]>
Date: Tue, 22 Mar 2005 18:19:43 -0500

> |    vocabulary MAY appear at any location in an Atom document.

Propose to strike this sentence.

> |    Atom allows foreign markup anywhere in an Atom document.

Propose to keep this sentence.

> |    [W3C.REC-xml-names-19990114] elements as children. 

Propose to strike this sentence.

Propose to adjust the following sentence:

6.4 Extension Elements

Child elements of atom:entry and atom:feed are  considered "metadata" 
elements, and are described below.

to

Child elements of atom:entry, atom:feed, and Person constructs are 
considered "metadata" elements, and are described below.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 22 Mar 2005 15:41:23 -0800

<co-chair>
These feel consistent with the discussions so far.

Let's officially close discussion of draft-06 on Friday and go to our 
AD/last-call next week.
</co-chair>

>> | |    Atom allows foreign markup anywhere in an Atom document.
>
>> | |    The atom:entry element MAY contain any namespace-qualified
- Tim Bray, Director of Web Technologies, Sun Microsystems
   +1-877-305-0889 Sun ext. 60561
   http://www.tbray.org/ongoing/  AIM: MarkupPedant

---

From: David Powell <[email-masked]>
Date: Thu, 24 Mar 2005 23:43:21 +0000

One of the impacts identified [1] with PaceLangSpecific, was that we
needed to make a decision about the language-sensitivity of
extensions.

I didn't propose an amendment to PaceExtensionConstruct at the time,
because PaceExtensionConstruct had been accused by the chairs of being
"unstable" due to the amendments made following earlier feedback.

[Abstract]

Structured Extension constructs should be language-sensitive.

[Rationale]

Currently, the specification implies that Structured Extension
constructs are not language-sensitive. This means that they aren't
allowed to pay attention to in-scope xml:lang tags.

[Proposal]

In Section 6.4.2, add the sentence:

  Structured Extension constructs are language-sensitive.

[1] http://intertwingly.net/wiki/pie/PaceLangSpecific#head-261b3b049c9b50b9dda180b9fdb6257bd3b26248

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Fri, 25 Mar 2005 12:16:55 +1100

> Structured Extension constructs are language-sensitive.

+1

---

From: Robert Sayre <[email-masked]>
Date: Thu, 24 Mar 2005 22:44:17 -0500

+1

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Fri, 25 Mar 2005 09:42:45 +0100

+1 
looking good.

Note also:

3.2  Person Constructs
...
   Person constructs MAY be extended by namespace-qualified element
   children.

I'd suggest either striking this or (preferably) adding:
"See 6.4  Extension Elements".

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Norman Walsh <[email-masked]>
Date: Fri, 25 Mar 2005 15:03:44 -0500

/ "Thomas Broyer" <[email-masked]> was heard to say:
|> | though I wonder why interlaced content models are used instead of |
|> "ordered" content models... that would also allow DTD or XML Schema |
|> (or any other schema requiring deterministic content models) to be |
|> used to validate Atom documents...
|>
|> Because the spec says they aren't ordered.
|
| Well, by "ordered", I actually meant "non-interleaved", e.g. having a
| deterministic content model...

I don't know of any other way to model the constraints (and only the
constraints) imposed by the spec. If you have an alternate suggestion,
please send it along.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Resist the urge to hurry; it will only
http://nwalsh.com/            | slow you down--Bruce Eckel