Subject: Call for final Paces for consideration: deadline imminent

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Feb 2005 17:46:51 -0800

Greetings again. And, thanks again for all the work people did on the 
last work queue rotation. We now have the end of the format draft 
squarely in sight.

The WG still has a bunch of finished Paces that have not been 
formally considered, a (thankfully) much smaller number of unfinished 
Paces, and a couple of promises that "I'll write that up as a Pace 
soon". We need to finish soon in order to make our milestone, and I 
believe we can do so gracefully.

On Monday, Feb. 7, the Working Group's final queue rotation will 
consist of all Paces open at that time. Any Paces that have obvious 
holes in them ("to be filled in later", "more needs to go here", 
etc.) will be ignored. We have had over a year of time here, and many 
weeks since the previous attempt to close things out. On Monday, Feb. 
14, we will assess WG consensus and ask the document authors to put 
together a final draft.

Note that this is not the last opportunity for work on the Atom 
format. For one thing, there are plenty of non-core extensions that 
folks have been mulling over; having the core draft finally finished 
will help those to emerge. Further, we need to do the final work on 
the protocol document. Also, during the formal IETF Last Call, 
discussion of the format draft will be welcome from everyone 
(including people who have not read any of the earlier drafts).

Please do *not* rush out to write a Pace unless it is for something 
that is *truly* part of the Atom core, and you really believe that it 
is likely that there will be consensus within a week. If your idea is 
appropriate as an extension, or is for something that is quite 
similar to something else that has explicitly gotten lack of 
consensus, please do not write a Pace. In the former case, please 
hold your extensions for a few weeks; in the latter case, please 
recognize that asking the WG to focus on something that they don't 
want will likely cause us to do a worse job at carefully reviewing 
things that we all want.

So, if you have an incomplete Pace now, you have a few more days to 
complete it. Of course, everyone should feel free to continue talking 
about the current Paces now, and to continue to suggest editorial 
changes to the current Internet Draft.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Wed, 02 Feb 2005 21:57:05 -0500

Paul Hoffman wrote:

> Please do *not* rush out to write a Pace unless it is for something that 
> is *truly* part of the Atom core, and you really believe that it is 
> likely that there will be consensus within a week. 

Sorry, this is not a legitimate condition. If someone writes a Pace that 
points out a critical bug or missing feature in the format, and a 
significant number of WG participants agree, we should miss our deadline 
  because we no longer have consensus on the *current draft*.

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Feb 2005 19:28:14 -0800

At 9:57 PM -0500 2/2/05, Robert Sayre wrote:
>>that is *truly* part of the Atom core, and you really believe that 
>>it is likely that there will be consensus within a week.
>
>Sorry, this is not a legitimate condition. If someone writes a Pace 
>that points out a critical bug or missing feature in the format, and 
>a significant number of WG participants agree, we should miss our 
>deadline  because we no longer have consensus on the *current draft*.

First, let's differentiate "critical bug" from "missing feature".

A critical bug can (should!) be brought to the list at any time, even 
after IETF Last Call. Until the IESG has signed off on the document, 
critical bugs are always fair game for discussion. Even after the RFC 
is issued, critical bugs can (should!) be fixed with new RFCs.

As for "missing features", we have already been presented with 
literally dozens of missing features that the WG decided were not 
part of the Atom core. There are probably dozens more. We are 
explicitly putting those out of scope starting Monday because (a) the 
list is open-ended, (b) extensions to the core are fairly easy, and 
(c) the chance that a newly-discovered missing feature is really part 
of the *core* has been decreasing over the past year.

Clearly, we will make mistakes in this document. There are very few 
finished protocols that don't have design errors (some of them 
critical) and/or missing features. If anyone thinks that we need more 
time to search for those, please propose a fixed date by which you 
think we will be done. We can then spend really fun time on the list 
talking about process issues and, if consensus is reached, Tim and I 
can ask for a charter revision with the new milestones.

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Wed, 02 Feb 2005 22:48:11 -0500

> First, let's differentiate "critical bug" from "missing feature".

Let's not. Let's differentiate "missing feature" from "critical missing 
feature". None of the "organization" Paces could easily be added to the 
core. If it were up to me, and I had to turn the draft in tomorrow, I 
would strike PaceHeadInEntry, because "it can easily be added later".

> finished protocols that don't have design errors (some of them critical) 
> and/or missing features. If anyone thinks that we need more time to 
> search for those, please propose a fixed date by which you think we will 
> be done. 

Our charter:
---------------------------------------------------------
Goals and Milestones:
Mar 05	  	Request Last Call for Atom feed format
Mar 05	  	Request Last Call for Atom editing protocol
---------------------------------------------------------

These two deadlines seem to be the ones at hand. I don't know whether 
"Mar 05" means March 1 or March 31, but let's say it means March 1. 
Clearly, the format is on track for that deadline, while the protocol is 
not.

Since the chairs' proposed deadline for new Paces is February 7, please 
outline the process by which new text will make it in the draft between 
that date and March 1-31.

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Feb 2005 20:37:28 -0800

At 10:48 PM -0500 2/2/05, Robert Sayre wrote:
>Let's not. Let's differentiate "missing feature" from "critical 
>missing feature".

Let's not. :-) Looking over the archives, there are certainly pockets 
of people in the WG who consider particular features that the WG has 
failed to reach consensus on as critical. It could be critical to 
their business model, to their picture of what blogging is, to their 
picture of what is needed to gain critical mass over RSS 2.0, to 
their picture of what is needed for extensibility, to their picture 
of what is needed to work with other parts of the XML alphabet soup, 
and so on.

We do not have a way of defining "critical missing feature", and a 
group as diverse as this would be unable to come to consensus on such 
a definition in under a year, if then. This group would probably do 
what most IETF groups fighting with the same issue would do, namely 
cheat and make the "requirements" match the current document and piss 
everybody off in the process.

>  None of the "organization" Paces could easily be added to the core.

Agree. But that's why there is one more round of consensus-gathering: 
to see if WG wants to do it, even if it isn't easy.

>These two deadlines seem to be the ones at hand. I don't know 
>whether "Mar 05" means March 1 or March 31, but let's say it means 
>March 1. Clearly, the format is on track for that deadline, while 
>the protocol is not.

Maybe.

>Since the chairs' proposed deadline for new Paces is February 7, 
>please outline the process by which new text will make it in the 
>draft between that date and March 1-31.

Format draft:

Feb. 7: All Paces must be complete
Feb. 7: Begin formally discussing Paces so we can assess consensus
Feb. 14: Finish discussion on Paces, assess consensus, ask editors to 
issue another draft
Feb. 21ish: Get new draft
Feb. 21ish: Start intensive editorial review
March 1ish: Get another round of the draft including results of 
editorial review.
March 1ish: Pass this to our AD in preparation for IETF Last Call

Protocol draft:

Feb 14ish: Renew discussion of outstanding technical and editorial 
issues in the protocol
March 15ish: Try to close out draft
March 31ish: Pass this to our AD in preparation for IETF Last Call

All of these depend on what comes out of the WG process. Finding a 
critical bug in either spec could cause a delay because we need to 
agree on a fix and get another round of the draft. That's just fine.

--Paul Hoffman, Director

---

From: Walter Underwood <[email-masked]>
Date: Wed, 02 Feb 2005 20:36:20 -0800

The charter says that Atom will work for archiving. We don't know that
it will, and it hasn't been discussed for months.

Is the current Atom spec sufficient for archiving? If not, we aren't done.

wunder

--On February 2, 2005 5:46:51 PM -0800 Paul Hoffman <[email-masked]> wrote:

> 
> Greetings again. And, thanks again for all the work people did on the last work queue rotation. We now have the end of the format draft squarely in sight.
> 
> The WG still has a bunch of finished Paces that have not been formally considered, a (thankfully) much smaller number of unfinished Paces, and a couple of promises that "I'll write that up as a Pace soon". We need to finish soon in order to make our milestone, and I believe we can do so gracefully.
> 
> On Monday, Feb. 7, the Working Group's final queue rotation will consist of all Paces open at that time. Any Paces that have obvious holes in them ("to be filled in later", "more needs to go here", etc.) will be ignored. We have had over a year of time here, and many weeks since the previous attempt to close things out. On Monday, Feb. 14, we will assess WG consensus and ask the document authors to put together a final draft.
> 
> Note that this is not the last opportunity for work on the Atom format. For one thing, there are plenty of non-core extensions that folks have been mulling over; having the core draft finally finished will help those to emerge. Further, we need to do the final work on the protocol document. Also, during the formal IETF Last Call, discussion of the format draft will be welcome from everyone (including people who have not read any of the earlier drafts).
> 
> Please do *not* rush out to write a Pace unless it is for something that is *truly* part of the Atom core, and you really believe that it is likely that there will be consensus within a week. If your idea is appropriate as an extension, or is for something that is quite similar to something else that has explicitly gotten lack of consensus, please do not write a Pace. In the former case, please hold your extensions for a few weeks; in the latter case, please recognize that asking the WG to
focus on something that they don't want will likely cause us to do a worse job at carefully reviewing things that we all want.
> 
> So, if you have an incomplete Pace now, you have a few more days to complete it. Of course, everyone should feel free to continue talking about the current Paces now, and to continue to suggest editorial changes to the current Internet Draft.
> 
> --Paul Hoffman, Director

--
Walter Underwood
Principal Architect, Verity

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 16:02:15 +1100

> Is the current Atom spec sufficient for archiving? If not, we aren't done.

We might need a new @rel value or two.

Entries can be published in feeds which are then no longer updated. the spec
supports this as is. what we don't have is any easy way of navigating
through collections of archival feed documents.

The simplest thing that could possibly work is allowing @rel="next" and
@rel="previous".

A current feed (as distinct from an archival collection), could point to the
most recent archive with @rel="previous". It could also point to the start
of the archive with @rel="start".

I think it would also be interesting to codify a convention that
/feed/head/link[@rel="archives"] points to another feed which contains one
entry for each archival feed.

If we do start pointing to feeds from entries and so forth, I think we might
need to clarify the terms as previously discussed: what is currently an Atom
Feed Document becomes an Atom Collection Document, while a "feed" is a
special case of Atom Collection Document (no real differences in formatting,
just in usage - ie. ongoing publishing). I'm off to write a Pace right
now...

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 03 Feb 2005 00:01:59 -0500

Paul Hoffman wrote:
> Let's not. :-) Looking over the archives, there are certainly pockets of 
> people in the WG who consider particular features that the WG has failed 

> We do not have a way of defining "critical missing feature"

Agree. However, we do have a way to identify things Atom sucks at. We 
can point at them and it will be obvious. These are not pie-in-the-sky 
scenarios, or semantic nirvana--they exist right now. If the WG decides 
these are out of bounds, so be it.

Use cases here:
http://www.imc.org/atom-syntax/mail-archive/msg12963.html

1.) Atom sucks at web forums (e.g. slashdot)
2.) Atom sucks at LiveJournal
3.) Atom sucks at Netflix Top 100
4.) Atom sucks at blogs with comments or trackbacks
5.) Atom sucks at anything with a representation of its own and
     collection membership

I understand that Atom will not be perfect, but it's important to make 
it very obvious when something is left out intentionally.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 16:21:42 +1100

> 5.) Atom sucks at anything with a representation of its own and

<link href="..." type="application/atom+xml" rel="comments" />
<link href="..." type="application/atom+xml" rel="trackbacks" />
<link href="..." type="application/atom+xml" rel="parts" />

e.

---

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 22:09:10 -0800

Bear with me on this, I'm just throwing it out for the sake of the
conversation.

What is the model for archiving with Atom?  One or more distinct Atom
feeds that each contain a collection of old entries? If so, what we
need then is a just container for feeds.  One that encapsulates by
reference rather than by direct containment.  Perhaps a top level
document like the following would be sufficient?)

<!-- archive-index.xml -->
<index>
   <archive href="2001/archive-feed.atom">
      <title>Archive Title</title>
   </archive>
   <archive href="2002/archive-feed.atom">
      <title>Archive Title</title>
   </archive>
   <archive href="2003/archive-feed.atom">
      <title>Archive Title</title>
   </archive>
   <archive href="2004/archive-feed.atom">
      <title>Archive Title</title>
   </archive>
</index>

Just a single new @rel value for the link element in an atom feed head
can then be created that points to this archive index document.

<feed>
  <head>
    <link rel="archive" type="application/atom+xml" href="archive-index.xml" />
  </head>
</feed>

The nice thing about this approach is that it can be done completely
as an extension to the core rather than as a modification of the core
as it currently exists.  In other words, an "Atom Archive Format" RFC
can be written up separately from the core to handle the archive case.

Thoughts?

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

---

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 22:29:53 -0800

+1 Eric.  "sub-feeds" can easily be "nested" by reference using the
existing link mechanism as opposed to nesting by containment.  Overall
this would be a cleaner model and would be easier on bandwidth by
allowing nested feeds to be broken up over several documents rather
than stuffed all into a single document.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 17:27:33 +1100

>     <title>Archive Title</title>

Your example format doesn't include dates for when the referenced items were
last updated, nor unique IDs for disambiguation, etc etc ... why not
instead:

<feed>
    <head>
        <title>The 2001 Archive of My Big Fat Fenugreek Blog</title>
        [...]
    </head>
    <entry>
        <title>January 2001 Archive</title>
        <summary>208 posts over 19 days</summary>
        <link href="..." type="application/atom+xml" rel="alternate" />
        [...]
    </entry>
    <entry>
        <title>February 2001 Archive</title>
        <summary>311 posts over 23 days</summary>
        <link href="..." type="application/atom+xml" rel="alternate" />
        [...]
    </entry>
</feed>

>       <link rel="archive" type="application/atom+xml" href="..." />
>   </head>
>   [...]
> </feed>

this is exactly what I had in mind with PaceCollections.

e.

---

From: James Snell <[email-masked]>
Date: Wed, 2 Feb 2005 22:46:09 -0800

Comments below..

>         <link href="..." type="application/atom+xml" rel="alternate" />

This is better.  I guess I just hadn't grok'd the idea of using
entries to reference feeds, but now that I see the angle brackets I
get it.  (perhaps I just need some coffee).  As long as it is legal
for an "alternate" link to reference a feed document, this works
perfectly.   I like the containment-by-reference approach.  Best of
all, this could be accomplished without requiring any changes to the
existing core..

> this is exactly what I had in mind with PaceCollections.

Well, from your Pace: "Atom Feed Documents are properly collections,
of which "feeds" are just one semantic. Other semantics for Atom
Collection Documents include "archives", "directory", "comments",
"trackbacks", "pings", "parts", "versions", and so on."

If we define a "feed" as a collection of entries, archives,
directories, comments, trackbacks, pings, parts, versions, and so
forth, then the name "feed" is descriptive enough to get the point
across.  I'm not sure I follow the connection between PaceCollection
and the archive @rel attribute.  Did I miss something?

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 18:05:49 +1100

> "trackbacks", "pings", "parts", "versions", and so on."

hmmm ... you've caught myself mid-renaming. I can see how that can be
confusing. The first mention of Atom Feed Documents there would be the past
tense sense ... what I meant was:

    The thing we currently call "Atom Feed Documents" are properly [...]

Pace updated, thanks.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 03 Feb 2005 03:18:04 -0500

I'd just like to point out that this is not a new feature. Any 
half-decent aggregator already does this for you with grouped feeds. For 
example, in NetNewsWire, you can click on folder.

"Planet" feeds simulate this feature badly due to limitations in 
existing formats, but users like them because it eliminates lots of 
clerical work.

Robert Sayre

> than stuffed all into a single document.

Yes, sub-feeds can be nested by reference. Whether or not it's a net-win 
is probably variable.

James Snell wrote:

 > get it.

Yes, feeds are entries.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Thu, 03 Feb 2005 19:22:10 +1100

>> entries to reference feeds, but now that I see the angle brackets I

no, feeds are collections, entries describe resources, and while feeds are
also resources that only means that entries can describe feeds, not actually
be feeds.

e.

---

From: James Snell <[email-masked]>
Date: Thu, 3 Feb 2005 00:32:36 -0800

> also resources that only means that entries can describe feeds, not actually

+1 on "entries can describe feeds, not actually be feeds".  An entry
can reference a feed, but is not the feed itself.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 3 Feb 2005 13:31:45 +0200

On Feb 3, 2005, at 08:09, James Snell wrote:

> What is the model for archiving with Atom?

What's the *point* in archiving with Atom compared to eg. a zip archive 
with some HTML or XHTML files in it (with relative links and a 
stipulation that index.html and index.xhtml are magic names)?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Robert Sayre <[email-masked]>
Date: Thu, 03 Feb 2005 12:45:09 -0500

> also resources that only means that entries can describe feeds, not actually

I'm sorry, the whole point of my pace is that collections are resources. 
This is obviosly true. You just have to look at the flurry of Paces that 
resulted with hacky link relations to see that it's true.

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Thu, 03 Feb 2005 10:20:39 -0800

--On February 3, 2005 1:31:45 PM +0200 Henri Sivonen <[email-masked]> wrote:
> What's the *point* in archiving with Atom compared to eg. a zip archive with
> some HTML or XHTML files in it (with relative links and a stipulation that
> index.html and index.xhtml are magic names)?

Cross-platform dump and load. Saving data that is in the database and not
in the HTML. Backups. Dump and reload for an upgrade with a DB schema change.
Consistent save from a live database (hold a read lock while you dump the
archive). Insurance against your blog service going away on short notice.
Sarbanes-Oxley compliance for corporate blogs (internal and external).

And of course, so Brewster Kahle can keep a copy. The Wayback Machine
has saved my butt a couple of times.

wunder

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 3 Feb 2005 22:13:56 +0200

On Feb 3, 2005, at 20:20, Walter Underwood wrote:

> in the HTML.

Why couldn't you dump from a database to an (X)HTML entry in a zip 
archive if you can dump into a 'content' element in an Atom file?

> Backups. Dump and reload for an upgrade with a DB schema change.

What value does Atom as yet another container format add over .zip 
(perhaps with a metadata manifest as in .jar) or .mht?

Why would anyone, who so far has not implemented zip/mht dump and load, 
implement Atom dump and load?

(Compared to all competing Base64-in-text-or-XML aggregate document 
formats, zip-based OOo files are surprisingly elegant.)

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Antone Roundy <[email-masked]>
Date: Thu, 3 Feb 2005 13:38:22 -0700

> (perhaps with a metadata manifest as in .jar) or .mht?

It's readable by feed readers.

I think we're not all talking about the same meaning of the word 
"archive".  We aren't talking about what you do when you compress a 
bunch of files into a zip, tgz, sit...file.  We're not talking about 
Base64ing all your photos so that you can stuff them into a single Atom 
document for backup.  Unless I'm mistaken, we're talking essentially 
about using (relatively) static Atom documents to store the portions of 
a stream of entries (aka a "feed") that have passed through the 
"sliding window".

---

From: Tim Bray <[email-masked]>
Date: Thu, 03 Feb 2005 18:42:53 -0800

On Feb 2, 2005, at 5:46 PM, Paul Hoffman wrote:

...

> holes in them ("to be filled in later", "more needs to go here", etc.) 
> will be ignored. We have had over a year of time here, and many weeks 
> since the previous attempt to close things out. On Monday, Feb. 14, we 
> will assess WG consensus and ask the document authors to put together 
> a final draft.

...

In case it's not obvious, I am 100% with Paul on this.  I think that 
the Atom format as it stands now is very close to a huge 80/20 point, 
and the world needs it.  Also, I think that one or two of the last 
outstanding Paces will result in a noticeable positive delta.

It's like when you get towards the end of a software project.  The 
engineers always know that they could make it better in just another 
few weeks' work, and at some point you have to let go and turn it over 
to the world.

Let's get our last round of Paces nicely nailed down and cleaned up and 
polished and ready to take up officially on Monday. -Tim

---

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

Walter brings up an important point; has, or when will, the drafts be 
compared to the requirements in the charter?

Cheers,

On Feb 2, 2005, at 8:36 PM, Walter Underwood wrote:

>> recognize that asking the WG to
> focus on something that they don't want will likely cause us to do a 
> worse job at carefully reviewing things that we all want.
>>

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Feb 2005 09:34:47 -0800

At 8:55 PM -0800 2/3/05, Mark Nottingham wrote:
>Walter brings up an important point; has, or when will, the drafts 
>be compared to the requirements in the charter?

I have compared the format draft to the charter and it meets the 
requirements, at least in my eyes (which are the eyes of a protocol 
weenie but not a developer).

In specific, "a complete archive of all entries in a feed" is well 
taken care of by our current format; it's just not explicitly called 
"an archive". The fact that our IDs are unique over all time means an 
archive of all entries that were ever in the main feed is just a 
bigger feed; that will work exactly as an archive with no ambiguity 
of elements.

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 4 Feb 2005 14:56:14 -0500

> bigger feed; that will work exactly as an archive with no ambiguity
	Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed. (This rule is enforced by FeedValidator for Atom 0.3
documents... Sam? Mark?)
	If the prohibition against having more than one entry in a single
feed document with the same atom:id is still in effect, (i.e. if you can't
have multiple versions of an entry in a single feed document) then you can't
use an Atom feed document to archive "all states or versions" of entries as
they have been published over time. You would only be able to archive, at
best, a single version of each entry (typically the last one published, I
think).
	One alternative might to be provide an explicit relaxation of the
rules by saying that for at least archives, what must be unique is a
combined "key" constructed by concatenating atom:id + atom:modified. 

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Fri, 04 Feb 2005 12:04:36 -0800

> once in a single feed. (This rule is enforced by FeedValidator for 

Sounds like a bug to me.  I can't see any reason to rule this out. -Tim

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Feb 2005 12:29:11 -0800

At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
>once in a single feed.

The current draft says:

5.8  "atom:id" Element

    The "atom:id" element is an Identity construct that conveys a
    permanent, universally unique identifier for an entry.  atom:entry
    elements MUST contain exactly one atom:id element.

That means that you're not allowed to sue the same atom:id in any two 
entries, ever.

>feed document with the same atom:id is still in effect,

Yes....

>  (i.e. if you can't

The requirement in the charter is:
    * a complete archive of all entries in a feed
Your proposal expands that significantly. If you feel a need for that 
(quite different) kind of archive, you can propose an extension.

>combined "key" constructed by concatenating atom:id + atom:modified.

We don't need to define "archive" in the core format spec, certainly 
not in a way that will be confusing to people who only care about 
entries and normal feeds. That's what extensions are for.

--Paul Hoffman, Director

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 04 Feb 2005 21:43:33 +0100

>That means that you're not allowed to sue the same atom:id in any two 

It does not mean that once cannot have multiple versions of the same
entry in a feed (or duplicate entries for that matter).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 12:44:07 -0800

> That means that you're not allowed to sue the same atom:id in any two 

I don't read it that way, although I understand how you might infer 
that; there's too much wiggle room in the current text for that intent 
to be clear.

I.e., just because it's a "permanent, universally unique identifier" 
doesn't mean you're not able to use it twice to talk about a single 
entry; to RDF people, this will seem quite natural. If you want to only 
see one instance of an atom:id's content in the set of all entries ever 
published in any feed, you need to say that explicitly.

---

From: Graham <[email-masked]>
Date: Fri, 4 Feb 2005 21:00:30 +0000

On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:

> entry;

I disagree, as I've said before. The only literal interpretation is 
that you can't serve the same entry twice with the same id. We know it 
doesn't mean that, but the spec just doesn't define in which axis 
"unique" is meant to apply.

Graham

---

From: Tim Bray <[email-masked]>
Date: Fri, 04 Feb 2005 13:05:51 -0800

On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:

> entry; to RDF people, this will seem quite natural. If you want to 
> only see one instance of an atom:id's content in the set of all 
> entries ever published in any feed, you need to say that explicitly.

I'm with Mnot on this one.  Just because it uniquely identifies an 
entry, that doesn't mean you can't have two versions of the same entry 
in a feed.  Given that entries can show up in more than one feed, it is 
clearly the case that software is going to have to deal with multiple 
entries bearing the same ID in its input stream, so I don't see any 
reason for ruling them out in a single feed.

But, the spec needs to have no wriggle room.  Right now it's silent, it 
should be clear. -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 04 Feb 2005 21:06:45 +0000

> entry in a feed (or duplicate entries for that matter).

Conversely it does imply that if you do, you may (and possibly, must) 
assume that they are the same entry.

The problem: there's no easy way to distinguish between entry states and 
defective id allocation.

cheers
Bill

---

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

Graham, the issue here is that the spec can be interpreted in a number 
of ways, which is not good. You seem to agree with that below, correct?

Separately, there's the issue of what it *should* say. Tim and now you 
say that you have a good idea of what you want it to say; I'd be very 
interested to see how you'd specify that. Can you suggest some spec 
text?

---

From: Robert Sayre <[email-masked]>
Date: Fri, 04 Feb 2005 16:10:34 -0500

Graham wrote:
> I disagree, as I've said before. The only literal interpretation is that 
> you can't serve the same entry twice with the same id. We know it 

Hmm. The things URIs identify can change. What we really want to say is 
"don't be a bother and produce different entries with the same id" and 
"don't expect clients to keep separate records of entries with the same 
id". We should probably be more worried about bad implementions totally 
missing the point of "identifiers", than about good implementations with 
sophisticated notions of versioning and identifiers.

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Fri, 4 Feb 2005 22:38:58 +0100

A really clear way to specify this is to say that an id is a functional 
relation between
an entry and a identity construct.

This implies:
  -An Entry can only have one id.
  -Different Entries can have the same id.

Of course because there is a bit of a confusion as to what is meant by 
an Entry
the above sounds paradoxical.

It is a bit like the relation the body of a US citizen has to a social 
security number.
The body of a US citizen at a time has a functional relation to a SS 
number. Any such body
has only one SS number. But because when we eat and breath our bodies 
change it turns out
that different bodies have a relation to the same SS number. The 
different bodies, are time
slices of the same US citizen. The group of these time slices is 
identified by the social
security number. So that the relation between the SS number and  set of 
such citizen slices,
namely the relation between a SS number and the citizen is both 
functional and inverse functional.

When this group speaks about an Entry as it appears in the Feed

<feed>
	<entry>
		<id>tag:bblfish.net/entry1</id>
		...
	</entry>
     ...
</feed>

you are really speaking about an entry version. But because when people 
sit down and write
an entry they are looking at the present version of the entry, and this 
is what they use
to identify the sequence of entries that form the unique Entry over 
time, there is a confusion
of what is being talked about.

It is a little as if I spoke to someone and identified the body I am 
seeing at present
with the person that body is a temporal part of.

So when above I say:

  -An Entry can only have one id.
  -Different Entries can have the same id.

   What we mean is
  - the Entry Version can only have one id
  - any two Entry Versions that have the same id are different versions 
of the same Entry.

So now one should define what that type of entry is. And that is 
simple. It is the Collection
of all Entry Versions that have the same id.

Henry

On 4 Feb 2005, at 22:10, Mark Nottingham wrote:
>> that you can't serve the same entry twice with the same id. We know 
>> it doesn't mean that, but the spec just doesn't define in which axis

---

From: Graham <[email-masked]>
Date: Fri, 4 Feb 2005 22:04:57 +0000

> interested to see how you'd specify that. Can you suggest some spec 

As I suggested a couple of days ago:

Any two versions of the same entry must use the same id, [which 
requires that all characters are the same]. Any two different entries 
must have different ids, [which requires that at least one character is 
different]."

Graham

---

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

The term "version" seems out of place here. What you're saying, in 
effect, is that the ID acts as a hash of entry's content, correct? If, 
so, what value does it bring?

On Feb 4, 2005, at 2:04 PM, Graham wrote:

>> Separately, there's the issue of what it *should* say. Tim and now 
>> you say that you have a good idea of what you want it to say; I'd be 
>> very interested to see how you'd specify that. Can you suggest some 
>> spec text?
>
> must have different ids, [which requires that at least one character 
> is different]."
>
> Graham

---

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

Tim Bray wrote:

> entry, that doesn't mean you can't have two versions of the same
> entry in a feed.  ... I don't see any reason for ruling them out in a
> single feed.

Robert Sayre wrote:

> We should probably be more worried about bad implementions totally
> missing the point of "identifiers", than about good implementations
> with  sophisticated notions of versioning and identifiers.

With that in mind, I'm going to agree with Graham. What will happen is 
that super-simple implmentations that don't keep state will show both 
instances, because they don't bother with GUIDs. Then Graham will get 
bug reports saying "This feed only has nine entries in Shrook, but ten 
entries in TrivialServerSideScriptX, why is Shrook so broken?" We need 
to make that feed invalid, and Graham's life easier. Sophisticated 
implementations can assert common ancestry with an extension element.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Fri, 4 Feb 2005 15:12:55 -0700

> "unique" is meant to apply.
"3.5  Identity Constructs     An Identity construct is an element whose 
content conveys a permanent, universally unique identifier for the 
construct's parent."

Sure, if you really want to get nit-picky, this sentence when read in 
isolation says that the XML which is the parent of the ID construct is 
the only thing that may ever use this identifier.  Taking this nit-pick 
to its extreme, you could say this means that its a violation to use 
the same ID for the entry on your hard drive and the entry in RAM, or 
perhaps even a violation to use the same ID for the entry in RAM across 
refreshes of the RAM, since different electrons are involved--or maybe 
even across instants in time, depending on the true nature of the 
space-time continuum.  Obviously, at some point, the nit-picking gets 
ridiculous.  We might resolve the nit-pick with language like this 
(which is a bit over the top):

"An Identity construct is an element whose content conveys an 
unchanging identifier which MUST be universally unique within Atom 
Documents to the set of all versions and instantiations of the resource 
that the construct's parent instantiates."

I personally expect people to understand the existing spec text as 
intended, especially within the context of what follows.  For example:

    When an Atom document is relocated, migrated, syndicated,
    republished, exported or imported, the content of its Identity
    construct MUST NOT change.  Put another way, an Identity construct
    pertains to all instantiations of a particular Atom entry or feed;
    revisions retain the same content in their Identity constructs.

This makes it unmistakably clear that we were NOT talking about the ink 
that formed the specific XML that someone wrote down on their napkin, 
but "all instantiations" and "revisions".

---

From: Graham <[email-masked]>
Date: Fri, 4 Feb 2005 22:18:57 +0000

>> must have different ids, [which requires that at least one character 

It says different versions must have the same id. How is that a hash?

Graham

---

From: Antone Roundy <[email-masked]>
Date: Fri, 4 Feb 2005 15:22:18 -0700

On Friday, February 4, 2005, at 02:05  PM, Tim Bray wrote:
>>> That means that you're not allowed to sue the same atom:id in any 
>>> two entries, ever.
>>
>> that; there's too much wiggle room in the current text for that 
>> intent to be clear.
>>
> in a feed.  Given that entries can show up in more than one feed, it 
> is clearly the case that software is going to have to deal with 
> multiple entries bearing the same ID in its input stream, so I don't 
> see any reason for ruling them out in a single feed.
>
> But, the spec needs to have no wriggle room.  Right now it's silent, 
> it should be clear. -Tim

The following language should make things clear:

First, if we want to be able to put multiple revisions of an entry into 
a single Atom Feed Document (note: I'm talking about a document, not 
the abstraction called a feed), or multiple portions or versions of a 
feed into a single Atom Aggregation Document, if such a thing ever 
comes to exist:

"An Atom Document MAY contain multiple versions of the same resource, 
in which case the content of the Identity construct for each would be 
identical."

Second, if we don't want that to be possible:

"An Atom Document MUST NOT contain more than one version of the same 
resource.  Thus, no two resources in a single Atom Document can have 
the same content in their Identity constructs."

---

From: Antone Roundy <[email-masked]>
Date: Fri, 4 Feb 2005 15:31:10 -0700

On Friday, February 4, 2005, at 03:04  PM, Robert Sayre wrote:
> Sophisticated implementations can assert common ancestry with an 
> extension element.
Could you elaborate a little on this.  If we forbid putting two 
revisions of the same entry into a single document (unless you change 
the ID between revisions...please, I hope that's not what's being 
suggested), then what could an extension do?

---

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

When you talk about characters being the same or different, are you 
saying in the entry, or in the id?

On Feb 4, 2005, at 2:18 PM, Graham wrote:

>> effect, is that the ID acts as a hash of entry's content, correct? 
>> If, so, what value does it bring?
>
> Pardon:
>
>>> requires that all characters are the same]. Any two different 
>>> entries must have different ids, [which requires that at least one 
>>> character is different]."
>

---

From: Graham <[email-masked]>
Date: Fri, 4 Feb 2005 22:38:55 +0000

> saying in the entry, or in the id?

Oh, right. The id. That would be clear if the things in brackets were 
expanded (since "same" and "different" ids also need defining).

Graham

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Feb 2005 13:26:08 -0800

At 1:05 PM -0800 2/4/05, Tim Bray wrote:
>>I.e., just because it's a "permanent, universally unique 
>>identifier" doesn't mean you're not able to use it twice to talk 
>>about a single entry; to RDF people, this will seem quite natural. 
>>If you want to only see one instance of an atom:id's content in the 
>>set of all entries ever published in any feed, you need to say that 
>>explicitly.
>
>I'm with Mnot on this one.

So am I; I should have sad "...in any two different entries, ever". 
And an archive of a feed can have the entry many times, no problem.

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 4 Feb 2005 17:43:17 -0500

Paul Hoffman wrote:
> That means that you're not allowed to [use] the same atom:id in any
> two entries, ever.
	We have atom:modified in order to indicate that an instance is a
modified version of a previously published entry. The linkage between the
two instances of the entry is that they share a common atom:id.
	Forcing each instance of each entry to have a unique id would make
it impossible for us to do what users expect us to do in one aspect of
"duplicate" detection. i.e. Users don't normally want to see ever state of
an entry as it develops over time, what they typically want to see is the
most recent state of the entry. To provide this, we need a way to link
together the various versions or states of the entry -- that is done with
atom:id. Priority of the versions is determined using atom:modified...

		bob wyman

---

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

> suggested), then what could an extension do?

It's a trade-off. Make atom:id confusing to implementors and have poor 
interop with simple code, or require more complex code to jump through 
hoops. So, my suggestion is exactly what you'd feared. You could do an 
end run on the problem and pick a different delivery mechanism.

Robert Sayre

---

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

OK, so it sounds like this is just down to the slippery topic of 
defining what an entry is, or coming up with the appropriate weasel 
words the have the same effect without doing it.

I don't envy the editors on this one.

Uh-oh...

---

From: Antone Roundy <[email-masked]>
Date: Fri, 4 Feb 2005 16:23:26 -0700

On Friday, February 4, 2005, at 03:12  PM, Antone Roundy wrote:
> Documents to the set of all versions and instantiations of the 
> resource that the construct's parent instantiates."

Okay, getting serious now, there is room for clarification.  How about 
we replace this:

> "3.5  Identity Constructs
> An Identity construct is an element whose content conveys a permanent, 
> universally unique identifier for the construct's parent."

with this:

3.5  Identity Constructs

An Identity construct is an element whose content conveys a permanent, 
universally unique identifier for the resource (instantiated|described) 
by the construct's parent element.  An Atom Document MAY contain 
multiple (revisions|versions) of the same resource, in which case the 
content of the Identity construct for each would be identical. 
Applications MAY decline to display more than one version of each 
resource.

Comments?  Preferences?  Better ideas?  Is it ready for a Pace?

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2005 16:06:09 -0800

Just a note; I'm planning to remove the Identity Construct from -06, 
because it's only used in one place (the definition of atom:id). 
Otherwise, this sounds like a reasonable start.

On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:

>> An Identity construct is an element whose content conveys a 
>> permanent, universally unique identifier for the construct's parent."
>
> with this:
>
> 3.5  Identity Constructs
>
> universally unique identifier for the resource 
> (instantiated|described) by the construct's parent element.  An Atom 
> Document MAY contain multiple (revisions|versions) of the same 
> resource, in which case the content of the Identity construct for each 
> would be identical. Applications MAY decline to display more than one 
> version of each resource.
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

---

From: Tim Bray <[email-masked]>
Date: Fri, 04 Feb 2005 16:10:51 -0800

On Feb 4, 2005, at 2:43 PM, Bob Wyman wrote:

> modified version of a previously published entry.

We do?  I don't think so. -Tim

---

From: Tim Bray <[email-masked]>
Date: Fri, 04 Feb 2005 16:24:21 -0800

> Okay, getting serious now, there is room for clarification.  How about 

You guys are making good progress, I'm impressed.  Now please don't 
forget to Pace-ify whatever you end up with for Monday. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 04 Feb 2005 18:34:19 -0500

Antone Roundy wrote:
> Applications MAY decline to display more than one version of each resource.
> 

It doesn't make a bit of sense unless you define "entry" and "feed", as 
has been pointed out numerous times over the past few days. This text is 
defining a feed in the text on atom:id, which should be short.

If you define feed as a "sliding window on a stream of entries", your 
definition makes sense. If you define feed as a "server-determined 
representation of the current status of a set of entries", then it only 
makes sense to include one entry per atom:id. I would argue the second 
definition makes a lot more sense and accurately reflects real-world 
usage, where even the RDF formats recommend against repeating rdf:about.

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 4 Feb 2005 19:38:34 -0500

Clearly, I meant atom:updated not atom:modified... My apologies for the
slip.

		bob wyman

---

From: Henry Story <[email-masked]>
Date: Sat, 5 Feb 2005 09:54:42 +0100

On 5 Feb 2005, at 00:34, Robert Sayre wrote:
>> permanent, universally unique identifier for the resource 
>> resource, in which case the content of the Identity construct for 
>> each would be identical. Applications MAY decline to display more 
>> than one version of each resource.
> It doesn't make a bit of sense unless you define "entry" and "feed", 
> as has been pointed out numerous times over the past few days. This 
> text is defining a feed in the text on atom:id, which should be short.
>
> representation of the current status of a set of entries", then it 
> only makes sense to include one entry per atom:id. I would argue the 
> second definition makes a lot more sense and accurately reflects 
> real-world usage, where even the RDF formats recommend against 
> repeating rdf:about.

I would argue that you are completely wrong on this one. It is the 
first sliding
window version that represents current usage a lot better. When people 
move their
feed document to the archive, the easiest way to do this, is just to 
copy the
live feed document over to a new timestamped file and change the next 
and
previous links. Your suggestion would mean they would have to go 
through all
the archived versions (the feed documents you get to by following the 
"next" links
in sequence), and eliminate all duplicate entries. That is a lot more 
time
consuming.

I find it really good in fact that people should be able to keep a 
history of
the changes they make to their entries. That is the honest thing to do. 
Those who
want to cheat can also get what they want by deleting previous entries. 
But it
will require more work.

In any case the current system is I think very well defined. I am +1 on 
it
remaining this way, and would be seriously distraught at seeing it go. 
I am in
fact amazed that this should come up so late in the discussion here. No 
wonder
this group can't get any further along. The basic model is not even 
agreed to
by everyone.

As for the whole text on Identity constructs it is again one of those 
useless
pieces of text that the group is forced to write out because of its 
refusal to
use the appropriate tools. If you had used RDF as a model for what you 
are trying
to write then you would long ago have finished the document, and it 
would be a lot
shorter and clearer too.

Henry

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 09:18:34 -0700

http://www.intertwingly.net/wiki/pie/PaceRepeatIdInDocument

Abstract

Explicitly state that multiple versions of the resource identified by a 
particular atom:id may appear in the same document. Also, clarify 
somewhat what the atom:id must be unique to.

Rationale

    1. In order to show the revision history of a particular entry, 
multiple revisions of the entry must be able to appear in the same 
document.
    2. Changing the atom:id of the entry with each revision would 
severly reduce the duplicate detection value of atom:id.

Proposal

Replace the first sentence of section 3.5 of 
draft-ietf-atompub-format-05.txt with the following (with the choice of 
alternate terms left to comments made during discussion and the 
discretion of the editors):

An Identity construct is an element whose content conveys a permanent,
universally unique identifier for the resource (instantiated|described)
by the construct's parent element.  An Atom Document MAY contain 
multiple
(revisions|versions) of the same resource, in which case the content of
the Identity construct for each would be identical. Applications MAY
decline to display more than one version of each resource.

---

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 16:28:46 +0000

> multiple revisions of the entry must be able to appear in the same 

But "must" we have this facility?

> severly reduce the duplicate detection value of atom:id.

I don't think anyone's proposed this.

-1

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 05 Feb 2005 17:00:12 +0000

> I don't think anyone's proposed this.

-1 also. I think we'd do better to focus on the specification text for 
id - that will be much more effective than adding qualifying text.  I 
think it falls under editorial work and requires no pace.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 12:25:15 -0500

Antone Roundy wrote:
>    2. Changing the atom:id of the entry with each revision would severly 
> reduce the duplicate detection value of atom:id.
> 

-1.

RSS1.0: "{item_uri} must be unique with respect to any other rdf:about 
attributes in the RSS document and is a URI which identifies the  item."

RSS1.1: "The value of each rdf:about attribute must be unique to the 
document"

RSS2.0: Doesn't say anything about it (surprise!). But, I don't think 
I've ever seen a document that duplicated them with your intended semantics.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 10:24:23 -0700

>> I don't think anyone's proposed this.

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

> think it falls under editorial work and requires no pace.
I have no idea what you mean by this comment.  Part of the purpose of 
the Pace does seek to improve on the specification text for id (see the 
abstract, and compare the proposed text to the current draft) for the 
benefit of those who don't think it's perfectly clear if you don't 
refuse to keep reading after the first sentence.  Do you think the 
proposed change doesn't help?  If not, how about a counter suggestion 
or at least something more concrete than "...that will be much more 
effective than adding qualifying text.  I think it falls under 
editorial work and requires no pace."

Do you not think that we need to specify whether or not multiple 
instances of a resource can appear in a single document (with the same 
atom:id)?  Language specifying that they may is hardly mere editorial 
work--it requires a decision by the working group to decide whether we 
do want to allow it or not.

Warning publishers that consumers might not display each version of a 
resource if the do choose to include multiple revisions in a single 
document might be considered editorial work, but there's certainly no 
reason not to include such language in a proposal whose primary purpose 
is to clarify whether putting multiple revisions in the document is 
allowed.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 10:41:19 -0700

> RSS1.1: "The value of each rdf:about attribute must be unique to the 

Neither of these is equivalent to atom:id--according to this text, the 
{item_uri} and rdf:about for a particular item could change each time 
you transmit the feed.  Whether we accept this Pace or not, that is not 
what is intend for atom:id.  Could you explain how these are in any way 
relevant to this Pace?

> I've ever seen a document that duplicated them with your intended 

Part of our charter is to define a format suitable for archiving feeds. 
  A number of people in the working group have expressed a desire to be 
able to archive the revision history of an entry--not just the latest 
version--which is a fairly natural thing to want to do with an archive 
format.  That's not something any RSS version has attempted as far as 
I'm aware.  Therefore, if we wish to accomplish this goal, we need to 
do things that no RSS version ever did.  Past history isn't necessarily 
a valid guide in this case.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 05 Feb 2005 18:20:54 +0000

Antone Roundy wrote:

> I have no idea what you mean by this comment.  

I mean this:

  1. I believe the editors can and will fix the specification text to be 
more precise.

  2. I believe 1 does not require a pace.

> Part of the purpose of 
> proposed change doesn't help?  If not, how about a counter suggestion or 
> at least something more concrete than "...that will be much more 
> effective than adding qualifying text.  I think it falls under editorial 
> work and requires no pace."
 >
> atom:id)? 

You don't know how far I've read into the pace, and asking me loaded or 
presumptive questions won't persuade me to change my mind.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 13:48:06 -0500

> what is intend for atom:id.  Could you explain how these are in any way 

I'm sorry, that's nonsense. We don't get to make up how syndication 
works. I understand the thinking behind your proposal, but it *doesn't 
work*.

> Part of our charter is to define a format suitable for archiving feeds. 

Right, and breaking the feed format isn't the way to do it. Since you're 
advocating versioning, what are your plans for versioning the state of 
the feed itself? What if the title changes? It would be better to 
archive a series of feed documents.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 11:57:56 -0700

On Saturday, February 5, 2005, at 11:20  AM, Bill de hÓra wrote:
> Antone Roundy wrote:
>>> -1 also. I think we'd do better to focus on the specification text 
>>> for id - that will be much more effective than adding qualifying 
>>> text.  I think it falls under editorial work and requires no pace.
>>>
>  1. I believe the editors can and will fix the specification text to 
> be more precise.
>
>> Part of the purpose of the Pace does seek to improve on the 
>> specification text for id (see the abstract, and compare the proposed 
>> text to the current draft) for the benefit of those who don't think 
>> it's perfectly clear if you don't refuse to keep reading after the 
>> first sentence.  Do you think the proposed change doesn't help?  If 
>> not, how about a counter suggestion or at least something more 
>> concrete than "...that will be much more effective than adding 
>> qualifying text.  I think it falls under editorial work and requires 
>> no pace."
> >
>> instances of a resource can appear in a single document (with the 
>> same atom:id)?
>
> You don't know how far I've read into the pace, and asking me loaded 
> or presumptive questions won't persuade me to change my mind.
>
Sometimes I think the "Rationale" sections of Paces do more harm than 
good because we end up discussing the authors' stated reasons for what 
they propose, which aren't going to be in the spec, and don't discuss 
the proposed text, which is.  Of course, the rationale is not 
irrelevant--its relationship to the spec is similar to the Federalist 
Papers' relationship to the U.S. Constitution[1]--if a question arises 
over what a part of the spec means, the rationale section of the pace 
that introduced the spec text is a useful guide.  But its definitely 
secondary to the proposed text.

That said, yes, some imperfections may be appropriately left to the 
editors to address without needing paces.  In this case, I respectfully 
disagree about whether this is a simple editorial issue.

[1] The Federalist Papers is a series of of articles published under a 
pseudonym before the U.S. Constitution was adopted, written by 
Alexander Hamilton, James Madison, and John Jay, discussing the 
rationale for various parts of the proposed constitution.

---

From: Henry Story <[email-masked]>
Date: Sat, 5 Feb 2005 19:59:57 +0100

On 5 Feb 2005, at 19:48, Robert Sayre wrote:
> Antone Roundy wrote:
>
>> Neither of these is equivalent to atom:id--according to this text, 
>> the {item_uri} and rdf:about for a particular item could change each 
>> time you transmit the feed.  Whether we accept this Pace or not, that 
>> is not what is intend for atom:id.  Could you explain how these are 
>> in any way relevant to this Pace?
>
> Right, and breaking the feed format isn't the way to do it. Since 
> you're advocating versioning, what are your plans for versioning the 
> state of the feed itself? What if the title changes? It would be 
> better to archive a series of feed documents.

Oh. I think here there are two elements to answer this:

  1. A feed is not something that can be archived. This is to
     do with a feed properly speaking being at the interaction

  2. the feed head (which is in fact just a special entry that
     describes the feed) can have versions just like any other
     entry. These can be identified as being different version
     of the same entry by their id attribute, just as any other
     entry can.

Henry Story

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 12:15:33 -0700

> better to archive a series of feed documents.
Okay, I don't imagine you're going to like this, but here's a 
possibility:

<aggregation>
	<feed>
		<head>
			<id>1</id>
			<title>Foo Feed</title>
		</head>
		<entry>
			...
		</entry>
		<entry>
			...
		</entry>
		...
	</feed>
	<feed>
		<head>
			<id>1</id>
			<title>Foo Fighter Feed</title>
		</head>
		<entry>
			...
		</entry>
		<entry>
			...
		</entry>
		...
	</feed>
	<feed>
		<head>
			<id>1</id>
			<title>Bar Fight Feed</title>
		</head>
		<entry>
			...
		</entry>
		<entry>
			...
		</entry>
		...
	</feed>
</aggregation>

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 5 Feb 2005 15:22:37 -0500

Antone Roundy wrote:
> A number of people in the working group have expressed a desire to
> be able to archive the revision history of an entry--not just the
> latest version--which is a fairly natural thing to want to do with
> an archive format.  That's not something any RSS version has
> attempted as far as I'm aware.
	This is something that we actually do at PubSub for internal
purposes. Basically, we produce very large "log files" which are,
effectively, Atom files. These files contain a concatenation of all the
updated entries that we've discovered -- in the sequence we discovered them.
Each of the entries has a <ps:source-feed> element (our temporary equivalent
of HeadInEntry or Feeder) so that we can map an entry back to the feed that
it came from and have a permanent record of the feed metadata at the time we
found the entry. The atom:id's of entries in these files are the ones with
which they were published or atom:ids that we created to cover for entries
that were published without atom:ids. A single file can contain multiple
instances of entries that share the same atom:id. 
	What we have is very large atom feed documents that contain all
discovered states of entries and, in the case where an entry appears in
multiple source feeds, all copies of all entries from all feeds. This is an
effective and simple archival format. Undoubtedly, we could do all sorts of
things to make a more robust format -- but the degree of benefit received
for the additional cost is not immediately and apparently compelling.
	As long as multiple instances/versions of an entry are permitted to
exist in a single atom document while sharing the same atom:id, the current
Atom document format provides a useable "archive format." 

	The only real issue we have with this system is the fact that
although the Atom specification requires that atom:ids be globally unique
there is no defined mechanism or convention to ensure such uniqueness. Thus,
we are forced to assume that atom:ids are at best unique within the context
of a single source-feed. The *real* unique identifier for an entry thus
becomes <source-feed>+<atom:id>. This means that we can't do cross-feed
duplicate detection based soley on atom:id. To do cross-feed duplicate
detection we have to rely on textual analysis, a variety of heuristics, and
other bits of guesswork. However, this is not a problem specific to
"archiving." It is a problem with the definition of atom:id and will impact
any atom processor that attempts to meld content from multiple feeds into a
single view. This problem is very unfortunate when you realize that Entry
Documents aren't always associated with Feeds... Thus, one must fabricate a
"feed" context for the atom:ids found in Entry documents if you want to mix
feed-independent Entry Documents with Entries that come from feeds. (Note:
Most existing "news aggregators" don't concern themselves with these issues
since they typically present feed-oriented rather than entry-oriented views
of data and existing news aggregators have yet to deal with the issue of
Entry Documents that exist outside feeds. Because of their feed orientation,
existing news aggregators violate the principle of "It's about the Entries,
Stupid!" Hopefully, this will change.)

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 16:07:43 -0500

Antone Roundy wrote:
> Okay, I don't imagine you're going to like this, but here's a possibility:
> 
> <aggregation>
>     <feed>
>         <head>  ...

You're right! I think it's vile :). It would be reasonable to want a 
title for the root. Perhaps the location of an HTML version would be 
good to know as well... oops.

How about this. A series of feeds is probably overkill... I'd just use 
subversion. So, let's take a look at what Bob said:

> Atom document format provides a useable "archive format." 

This is clearly a non-starter for a syndication format, since ignoramus 
apps that don't keep a history will show more entries in a feed than 
ones that do. hmm...

Also, there's mnot's suggestion that there should be an archiving 
"profile". I don't really like all the baggage with profiles and 
mustUnderstand and all that. Why don't we just define an element called 
<archive> that acts exactly like <feed> except for the id restriction. 
This approach also happens to be "mustUnderstand". Could you live with that?

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 5 Feb 2005 16:41:18 -0500

Robert Sayre wrote:
>> exist in a single atom document while sharing the same atom:id, the 
>> current Atom document format provides a useable "archive format."
> apps that don't keep a history will show more entries in a feed than ones
>that do. hmm...
	So what? "Ignoramus apps" will do all sorts of things that don't
make sense. Why in the world would we define a new "<archive>" document type
simply because part of the world's population is of non-optimal
intelligence? If "ignoramus apps" display too many entries, users will
either shun them or pester their developers with demands that they fix the
bugs. The marketplace has many mechanisms to address this and similar
problems. We don't need to write spec text to address this issue. If
anything we should address the lack of a standard method for creating
atom:id's and we should create a requirement that atom:updated must be
changed on *every* update -- not just on the whim of the entry author... 
	It is all this informality and hand-waving around atom:id and
atom:updated that is the source of any trouble with using atom:feed as an
archive format. Given globally unique ids (atom:id) and version tags
(atom:updated) for entries, archiving would be trivial even for "ignoramus
apps".

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 16:45:28 -0500

> changed on *every* update -- not just on the whim of the entry author... 

Oh yes, let's rehash the date and id discussions.

> (atom:updated) for entries, archiving would be trivial even for "ignoramus

Sorry, Bob. You're not arguing with me. You're arguing against every 
other syndication format that does identifiers. I don't particularly 
care if we change it, we'll just look incredibly foolish and impractical.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 17:12:21 -0500

> (atom:updated) for entries, archiving would be trivial even for "ignoramus

BTW, if it weren't for the atrocious design error of banning recursive 
feeds, we wouldn't even be having this argument. A feed would always 
mean "current status", while a series of them would mean "stream".

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sat, 05 Feb 2005 17:55:53 -0500

Robert Sayre wrote:
>> you transmit the feed.  Whether we accept this Pace or not, that is 
>> not what is intend for atom:id.  Could you explain how these are in 
>> any way relevant to this Pace?
> 

-1 to the Pace.

Like Robert, I believe that this Pace breaks the feed format.  Here is a 
*recent* example of somebody who associated the same id (in this case 
rdf:about) with different entries:

http://sourceforge.net/mailarchive/message.php?msg_id=10636557

I would prefer a solution whereby if somebody wants to include versions 
of entries into a feed they need to include a version specific 
identifier.  Or that we define a third type of Atom document in section 
2, namely an atom:archive.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 18:19:58 -0700

> -1 to the Pace.

Just to be sure we don't forget, if we don't want to allow multiple 
versions of an entry in the same feed document, we need to add language 
to the spec to clarify that point.

> Like Robert, I believe that this Pace breaks the feed format.  Here is 
> a *recent* example of somebody who associated the same id (in this 
> case rdf:about) with different entries:
>

Without the Pace, the feed wouldn't validate...and who knows exactly 
how applications would handle the entries in question.  With it, the 
feed would validate, but the entries in question would be handled 
incorrectly since they'd be considered the same entry.  Either way, 
buggy feeds are bad.

> I would prefer a solution whereby if somebody wants to include 
> versions of entries into a feed they need to include a version 
> specific identifier.  Or that we define a third type of Atom document 
> in section 2, namely an atom:archive.

Of the two, I'd strongly prefer an archive document type.  Requiring a 
version specific-identifier and another identifier or method to tie all 
the versions together seems unnecessarily complex.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 18:25:57 -0700

> good to know as well... oops.

I left that out of the example, but sure (<aggregation> has a <head> in 
PaceAggregationDocument):

<aggregation>
	<head>
		<title>Archive of feed XYZ</title>
		<updated>...</updated>
		<link .... />
	</head>
	<feed>
		...

>> current
> This is clearly a non-starter for a syndication format, since 
> ignoramus apps that don't keep a history will show more entries in a 
> feed than ones that do. hmm...
>
> mustUnderstand and all that. Why don't we just define an element 
> called <archive> that acts exactly like <feed> except for the id 
> restriction. This approach also happens to be "mustUnderstand". Could 
> you live with that?
>
This would not address your question of tracking changes to the feed's 
metadata.  I'd be perfectly happy with not allowing atom:id to be 
repeated in a <feed> or the hypothetical <aggregation> if we had an 
<archive> element which acts exactly like <aggregation> except that 
atom:id may be repeated.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 18:41:30 -0700

On Saturday, February 5, 2005, at 06:25  PM, Antone Roundy wrote:
> I'd be perfectly happy with not allowing atom:id to be repeated in a 
> <feed> or the hypothetical <aggregation> if we had an <archive> 
> element which acts exactly like <aggregation> except that atom:id may 
> be repeated.
>
Oops, correction: I'd be perfectly happy with not allowing atom:id to 
be repeated in an Atom Feed Document or the hypothetical Atom 
Aggregation Document if we had an Atom Archive Document type (with an 
<atom:archive> element as its document element) which acts exactly like 
an Atom Aggregation Document, except that the atom:ids of the <feed>s 
and <entry>s in it could be repeated.  I wouldn't particularly care 
whether an Atom Archive Document were allowed to archive multiple 
feeds, or whether it were limited to archiving a single feed (ie., all 
of it's <feed>s would be required to have the same <id>).

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 20:49:55 -0500

> <archive> element which acts exactly like <aggregation> except that 

Nah, overkill. If there's an element like atom:head or atom:source-feed 
in atom:entry, the only changes that would be missed are changes to the 
number of entries in the feed. If you want an element that acts just 
like a feed, but isn't one so there can be no recursion, I think it's a 
gross hack. So, perhaps atom:archive shouldn't define anything besides 
atom:entry.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 06 Feb 2005 14:54:26 +1100

On 6/2/05 8:41 AM, "Bob Wyman" <[email-masked]> wrote:

> If

arrgh!

atom:updated was proposed and accepted because it provided the
noise-reduction feature of "author whim".

atom:modified was shouted down because (I suspect) people were sick of
discussing dates, and because it was argued that if two entries though
technically different in some content/metadata was not "significantly"
different enough in the publishers opinion then it was acceptable that the
newer version could be safely dropped on the floor.

At the time I argued that we need both, and that without atom:modified that
atom:updated would get polluted with every nitpicky modification under the
sun, thus destroying the original motivation for an <updated> date over a
<modified> date. And now you are proposing to enshrine that pollution into
the spec. Like I said: arrgh!

If you want atom:modified, you need to write a pace, and you need to really
bolster the rationale with all the use cases that require it, and be
prepared for a lot of resistance based not on the logic of the element, but
instead on a false logic of it having been discussed before (completely
ignoring any new and presumably stronger rationale in the pace). Religion is
like that.

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 06 Feb 2005 15:05:10 +1100

On 6/2/05 9:55 AM, "Sam Ruby" <[email-masked]> wrote:

> identifier.

+1.

e.