Subject: Review of draft-ietf-atompub-format-02.txt

From: Tim Bray <[email-masked]>
Date: Thu, 09 Sep 2004 15:42:27 -0700

1. Introduction

I'd like a slight rewrite of the introduction to say what Atom *is* 
rather than what we currently think it might be used for - as a result 
of the XML experience, I'm keenly aware how poorly we can expect to 
predict how Atom is going to be used.  For the first two paragraphs I 
suggest:
===========================
Atom is an XML-based document format that provides packages of metadata 
about resources called "Entries" and groups them into aggregations 
called "Feeds"; feeds also contain metadata about the aggregation.  For 
example, both Feeds and Entries have a title, and individual entries 
may have content summaries.

The design of Atom was driven by use cases involving the syndication of 
Web content such as Weblogs and news headlines.  Nothing in the design, 
however, should limit it to use in this class of application.
===========================

1.2 Example

The example is problematic in that it uses an unregistered URI scheme, 
"tag:".  I'm trying to think of some other scheme (or URN namespace) 
that will avoid provoking a storm of controversy... any ideas?

2. Atom Documents

4th para: rephrase from "MUST be well-formed XML" to "Atom Documents 
must be XML 1.0 documents [ref]; this implies that they are well-formed 
in the sense of the XML 1.0 specification."  The term "XML Document" is 
normatively defined in XML 1.0 and should be used at least once.

para beginning "Atom constrains": the word "appearance" is kind of 
puzzling; I assume you mean "occurrence" or "placement"?

para about xml:base: We want xml:base to apply, for example, to 
relative URIs in the (X)HTML found in <atom:content>; need to make sure 
this is covered somewhere.  I think the write-up on Content (or maybe 
soon Text) constructs.

[[feedback... ]] note: My opinion is that these are helpful as stated 
and strike about the right balance of brevity and thoroughness.

3.5.1 Dereferencing...

I note the use of the word "processors..."; we need to adopt (if we 
haven't already) consistent terminology to use in referring to 
software.  Processors is one possibility; others include "software", 
"agents", and "implementations".

4.1 "version" Attribute

What does "unstructured text" mean?  #PCDATA?

4.2.7 "atom:generator"..

I prefer "web" to "uri" for the attribute here; or "href"

5.6 "atom:updated"...

"that a publisher wants to bring to the attention of subscribers".  I 
think this presupposes the type of application.  Let's be simpler and 
say "consumers" instead; we don't care what/why/how they're consuming.

6. Managing feed state

I'm unconvinced that there will be useful content for this section, 
let's just lose it until we have some realistic proposals.  Same 
comment for 8. Embedding

7.1 Digital signatures

I think we achieved consensus on the child-only signature policy.  
Mark, I assume this is just one that slipped by you?

   -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 10 Sep 2004 00:33:11 -0400

> that will avoid provoking a storm of controversy... any ideas?
	Why bother doing this? It appears to be quite possible that
"tag:" will be registered by the time our document is finished. If tag:
is registered, it will be good to have it as an example. So, why not
just leave the example as it is and worry about it later? We could put
some text into the next draft that flagged it saying: "Check status of
tag: prior to final version." -- just to make sure it doesn't get
forgotten.

		bob wyman

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 10 Sep 2004 09:59:41 -0700

At 12:33 AM -0400 9/10/04, Bob Wyman wrote:
>"tag:" will be registered by the time our document is finished.

Anything is possible, but it is far from clear that this has much of 
a probability.

>  If tag:
>just leave the example as it is and worry about it later?

Because we should use other, registered schemes until we are sure. 
Since "http://" seems to get everyone's dander up in different 
directions, how about
    <id>mailto:[email-masked]?subject=2003:3.2397</id>

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 12 Sep 2004 12:23:53 +0200

> predict how Atom is going to be used.  For the first two paragraphs I  

+1. We have no idea what Atom might be used for, besides syndication. No  
need to enumerate the use cases, imho. Your introduction text looks fine,  
Tim.

> that will avoid provoking a storm of controversy... any ideas?

If NewsML URN loosened their specification to not exclude other formats,  
it might be used.

> puzzling; I assume you mean "occurrence" or "placement"?

«Occurence» sounds more fit, yes.

> I prefer "web" to "uri" for the attribute here; or "href"

Definately 'href'. It's most consistent with the rest of the link  
constructs.

> say "consumers" instead; we don't care what/why/how they're consuming.

Indeed. +1.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»