Subject: Re: PaceExtendingAtom

From: Henry Story <[email-masked]>
Date: Wed, 2 Feb 2005 18:06:53 +0100

-1.  At least I don't see why there should be limitations at all on 
where extensions can appear.
I am for a general must ignore rule.

On the other hand I think a much more ambitious extension spec would be 
one Atom were defined by
something similar to the RELAX NG description we currently have and an 
OWL ontology. This would
be helpful and very useful. PaceExtendingAtom as it currently is stated 
is restrictive without
being useful.

Henry Story

On 13 Jan 2005, at 19:27, Tim Bray wrote:
>
> +1
>
> I wrote it and I still think it's necessary as a bare-minimum measure. 
> -Tim
>

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 2 Feb 2005 14:01:25 -0500

> be helpful and very useful. PaceExtendingAtom as it currently is stated

How is PaceExtendingAtom restrictive? It only spells out a Must Ignore
policy and nothing else. Am I missing something?

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Henry Story <[email-masked]>
Date: Wed, 2 Feb 2005 20:40:33 +0100

[[
Also, Person Constructs, the atom:head element, and the atom:entry 
element
allow the inclusion of foreign markup.
]]

If one could add foreign markup anywhere then the above sentence would 
be
redundant.

Henry Story
http://bblfish.net/

---

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 11:58:07 -0800

I'm just thinking ahead a bit on this, but I am wondering if it would
be possible for those of us interested in proposing non-core
extensions to Atom to use the Wiki as the forum for sharing proposals
for extensions once the core syntax has been finalized?  What I
imagine is a system similar to Pace proposals except using a naming
prefix such as Ext instead.  E.g. ExtLinkContentDigest or
ExtFeedEntryLicense etc.  Discussion about the proposals would be
limited to the wiki or "private" email conversations (e.g. kept off
the ietf mailing list unless, for whatever reason, it is deemed
appropriate for list discussion by the WG chairs).  Thoughts?

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]

---

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 15:21:18 -0800

On Wed, 02 Feb 2005 15:18:46 -0800, Tim Bray <[email-masked]> wrote:
> 
> On Feb 2, 2005, at 11:58 AM, James Snell wrote:
> 
> >
> > for extensions once the core syntax has been finalized?
> 
> Sounds like a good idea to me.  Mind you, it's Sam's wiki :) -Tim
> 
> 

Heh, good point ;-) ... Sam? Ultimately it is your call.

---

From: Tim Bray <[email-masked]>
Date: Wed, 02 Feb 2005 15:18:46 -0800

---

From: Sam Ruby <[email-masked]>
Date: Wed, 02 Feb 2005 20:27:28 -0500

> Heh, good point ;-) ... Sam? Ultimately it is your call. 

Go4it.

- Sam Ruby

---

From: Danny Ayers <[email-masked]>
Date: Thu, 3 Feb 2005 11:46:14 +0100

> Go4it.

Yep, good idea. I can see a few in the intray: ipaddress/host (for
anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension
is in the process of being revised, and an Atom-compatible syntax is
planned; Yahoo's media object extension.

A Wiki template would be nice - have you started writing anything up yet, James?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: James Snell <[email-masked]>
Date: Thu, 3 Feb 2005 08:06:22 -0800

I will start working on the template this week and will get something
posted by the weekend.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Feb 2005 20:17:30 -0800

>         This specification describes Atom's XML markup vocabulary.  
> Markup from
>         other vocabularies ("foreign markup") can be used in Atom in a 
> variety of
>         ways. Text Constructs may contain foreign markup which SHOULD 
> be HTML or
>         XHTML.

What does this statement add? Why is HTML or XHTML normatively 
preferred over text, MathML, or any other vocabulary?

>         ==== 9.2 Extensions To the Atom Vocabulary ====
>
>         Future versions of this specification may add new elements and 
> attributes
>         to the Atom markup vocabulary.

What about extensions to the specification (as opposed to future 
versions)?

> 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 a 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.

*Anywhere*? As the root element? As attributes? As as child of atom:id? 
This is too permissive; it makes it too easy to change the semantics of 
an element or structure in an incompatible manner. Remember, Atom is a 
data format, not a markup format.

>         When unknown foreign markup is encountered as a child of 
> atom:entry,
>         atom:head, or a Person Construct, software SHOULD bypass the 
> markup and any
>         textual content and MUST NOT change its behavior as a result 
> of the
>         markup's presence.

Good, but what about requiring someone to understand an extension? If 
we don't introduce this before we go 1.0, we won't be able to introduce 
it until Atom 2.0 (I.e., never). This was the wall that HTTP hit, and 
one of the major drivers towards SOAP; I'd really prefer to avoid it 
this time around.

>         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.

This is bad. If I put a strict media type in my atom:content, I expect 
its requirements, restrictions and semantics to be honoured; if I'm 
required to hand it off to a processor, and have that processor 
understand arbitrary extensions, it's too high a bar; many formats and 
processors won't be designed to deal with that. Ignoring the markup but 
processing the text may have unintended consequences.

Might I suggest:

Extensions are allowed as:
   - Child elements of atom:head
   - Child elements of atom:entry
   - Child elements of elements which are Person constructs
   - Where particular elements defined by extension explicitly allow it.

Anywhere else, it's not an Atom Document.

Furthermore, children of atom:head and atom:entry MAY have a 
mustUnderstand attribute, with the usual semantics.

Finally, extensions MUST NOT contradict their containing elements' 
semantics.

--
Mark Nottingham     http://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Thu, 03 Feb 2005 23:27:21 -0800

On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:

>>         other vocabularies ("foreign markup") can be used in Atom in 
>> a variety of

It's not preferred over text, you can say type='TEXT', but since this 
is a *text* construct and quite likely to be presented in rows & 
columns (title, author, etc) simpler is better, so I'd think the SHOULD 
is sensible here. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 14:08:13 -0800

It certainly gives the impression that there's a preference; it's like 
saying "The language of the feed SHOULD be English;" there are lots of 
options, and we don't require one, but it does call one out.

Why is this a normative requirement, and what does adding this sentence 
bring to the spec?

On Feb 3, 2005, at 11:27 PM, Tim Bray wrote:

>>>         ways. Text Constructs may contain foreign markup which 
>>> SHOULD be HTML or
>>>         XHTML.
>>
> columns (title, author, etc) simpler is better, so I'd think the 
> SHOULD is sensible here. -Tim
>
>
>

---

From: Robert Sayre <[email-masked]>
Date: Fri, 04 Feb 2005 17:15:28 -0500

> Why is this a normative requirement, and what does adding this sentence 

TEXT, HTML, and XHTML are preferred because they interoperate.

"there may exist valid reasons in particular circumstances to ignore a 
particular item, but the full implications must be understood and 
carefully weighed before choosing a different course."

Seems right to me. If MathML titles become wildly popular, the spec can 
be revised later on.

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 14:20:02 -0800

Baking this as a normative requirement -- even a SHOULD -- into a 
standards-track RFC is a bad idea.

These formats are not the only interoperable formats on the planet, and 
in fact they all have interop problems to some degree.

In five years, this requirement isn't going to make any sense.

I've said my piece on this one; I'm interested in responses to my other 
questions and points.

Cheers,

On Feb 4, 2005, at 2:15 PM, Robert Sayre wrote:

> Mark Nottingham wrote:
>> It certainly gives the impression that there's a preference; it's 
>> like saying "The language of the feed SHOULD be English;" there are 
>> lots of options, and we don't require one, but it does call one out.
>> Why is this a normative requirement, and what does adding this 
>> sentence bring to the spec?
>
> Seems right to me. If MathML titles become wildly popular, the spec 
> can be revised later on.
>
> Robert Sayre
>
>