Subject: What kinds of Atom documents are there?

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 09:12:57 -0700

So far, the format spec defines one kind of Atom document, that with 
the atom:feed root element.

In the -00 draft, a Pace was incorporated that hints that entries might 
be documents on their own; that is, we might have a document whose root 
element is atom:entry.

Did this slip by without serious consideration by the WG, or does it 
represent consensus?

If it does, we need to add language about what that document is, and 
add a media type registration for it. I'm happy to start working on 
that, but want to make sure that this is the direction we want to go.

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

---

From: Robert Sayre <[email-masked]>
Date: Sat, 10 Jul 2004 12:44:49 -0400

> Did this slip by without serious consideration by the WG, or does it

I think it is the consensus. The protocol spec has always transferred such
documents. 

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

> that, but want to make sure that this is the direction we want to go.

Would we need a new media type for it? For example, application/docbook+xml
has more than one possible document element, right?

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 10:05:00 -0700

> has more than one possible document element, right?

I'm not aware of the situation of with docbook, but just because one 
format does it doesn't make it good practice.

If a document has a different format, a different syntax, a different 
processing model, and different use cases, and there are situations 
where you might want to negotiate for the different formats (e.g., 
allow people to GET either an entry or a list of entries from the same 
Web resource), it should have a different media type.

---

From: Ken MacLeod <[email-masked]>
Date: 10 Jul 2004 12:31:23 -0500

Mark Nottingham <[email-masked]> writes:

> In the -00 draft, a Pace was incorporated that hints that entries
> might be documents on their own; that is, we might have a document
> whose root element is atom:entry.
> 

PaceEntryTopLevel either borders or encompasses this, it looks like we
got crossed in the mail.

  -- Ken

PS. I'll followup on the "document type" issue to the replies already
in that direction.

---

From: Tim Bray <[email-masked]>
Date: Sat, 10 Jul 2004 10:49:19 -0700

>> has more than one possible document element, right?

I think one media type is plenty.

> Web resource), it should have a different media type.

I see the argument, but on balance I still think one media type is 
fine.  The set of scenarios where you're looking for an <atom:feed> are 
quite disjoint from those where you're looking for an <atom:entry> -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 10:58:23 -0700

What's the cost of having a separate media type? Can we foresee all 
possible uses of the different document types, and be confident that 
there won't be a need to disambiguate between them when doing content 
negotiation, typing links, etc.?

On Jul 10, 2004, at 10:49 AM, Tim Bray wrote:

>> allow people to GET either an entry or a list of entries from the 
>> same Web resource), it should have a different media type.
>
> fine.  The set of scenarios where you're looking for an <atom:feed> 
> are quite disjoint from those where you're looking for an <atom:entry> 
> -Tim
>

---

From: Mark Baker <[email-masked]>
Date: Sat, 10 Jul 2004 15:22:52 -0400

+1

> I think one media type is plenty.

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 03:43:28 +0200

> Did this slip by without serious consideration by the WG, or does it  

It at least represents _my_ consensus. ;)

> If it does, we need to add language about what that document is

PaceEntryTopLevel does a little to fix some of the formal stuff, but we  
need some more language about having <entry> as a document element, yes.  
I, at least, think that section 4.13.2 should say that <link  
rel="alternate" type="application/atom+xml" href="..." /> should point to  
an XML document with atom:entry as the document element.

> and add a media type registration for it.

Why is that needed? <feed><link rel="alternate"  
type="application/atom+xml" href="..." /></feed> should (MUST?) always  
point to an XML document with atom:feed as the document element, while  
<entry><link rel="alternate" type="application/atom+xml" href="..."  
/></entry> should (MUST?) always point to an XML document with atom:entry  
as the document element.

Other cases where you'll find 'application/xhtml+xml' I don't think it's  
very important to know in advanced what document element you'll meet when  
resolving the @href (or whatever).

PS and OT: Is there an HTML representation of the latest format  
specification draft?

____
[1] <url:  
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4.13.2>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 19:54:55 -0700

On Jul 10, 2004, at 6:43 PM, Asbjørn Ulsberg wrote:

> /></entry> should (MUST?) always point to an XML document with 
> atom:entry as the document element.

Are these the ONLY contexts where Atom documents are? Are we absolutely 
sure that there is no reason why anyone would want to disambiguate them 
at the MIME/HTTP layer (e.g., for caching, content negotiation, etc.).

The cost of registering one more media type is very low; I think the 
appropriate question is why it *isn't* needed.

> PS and OT: Is there an HTML representation of the latest format 

Not yet.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 16:09:14 +0200

On Sat, 10 Jul 2004 19:54:55 -0700, Mark Nottingham <[email-masked]> wrote:

> Are these the ONLY contexts where Atom documents are?

Probably not.

> Are we absolutely sure that there is no reason why anyone would want
> to disambiguate them at the MIME/HTTP layer (e.g., for caching, content
> negotiation, etc.).

Probably not, but there's imho no problem with going with  
'application/atom+xml' for both feeds and entries in the beginning, and  
rather add 'application/atom-feed+xml' and 'application/atom-entry+xml'  
(or something) when we find it necessary. I don't think it's necessary  
just yet, and not even sure it ever will be.

> appropriate question is why it *isn't* needed.

I don't really care whether Atom has one or ten MIME types. So if you  
manage to gather consensus about registering two separate for feeds and  
entries, I at least, won't stop you. ;-)

>> PS and OT: Is there an HTML representation of the latest format  

Please let the list know when it's done. :-)