Subject: PaceAllowDuplicateIDs

From: Tim Bray <[email-masked]>
Date: Wed, 04 May 2005 21:02:50 -0700

<co-chair-hat status="OFF">

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

This Pace was motivated by a talk I had with Bob Wyman today about the 
problems the synthofeed-generator community has.

Summary:
1. There are multiple plausible use-cases for feeds with duplicate IDs
2. Pro and Contra
3. Alternate Paces
4. Details about this Pace

1. Use-Cases

Here's a stream of stock-market quotes.

<feed><title>My Portfolio</title>
  ....
  <entry><title>MSFT</title>
   <updated>2005-05-03T10:00:00-05:00</updated>
   <content>Bid: 25.20 Ask: 25.50 Last: 25.20</content></item>
   </entry>
  <entry><title>MSFT</title>
   <updated>2005-05-03T11:00:00-05:00</updated>
   <content>Bid: 25.15 Ask: 25.25 Last: 25.20</content></item>
   </entry>
  <entry><title>MSFT</title>
   <updated>2005-05-03T12:00:00-05:00</updated>
   <content>Bid: 25.10 Ask: 25.15 Last: 25.10</content></item>
   </entry>
</feed>

You could also imagine a stream of weather readings.  Bob's actual 
here-and-now today use-case from PubSub is earthquakes, an entry 
describes an earthquake and they keep re-issuing it as new info about 
strength/location comes in.

Some people only care about the most recent version of the entry, 
others might want to see all of them.  Basically, each atom:entry 
element describes the same Entry, only at a different point in time.

You could argue that in some cases, these are representations of the 
Web resources identified by the atom:id URI, but I don't think we need 
to say that explicitly.

Yes, you could think of alternate ways of representing stock quotes or 
any of the other use-cases but this is simple and direct and idiomatic.

2. Pro and Contra

Given that I issued the consensus call rejecting the last attempt to do 
this, which was  PaceRepeatIdInDocument, I felt nervous about 
revisiting the issue.  So I went and reviewed the discussion around 
that one, which I extracted and placed at 
http://www.tbray.org/tmp/RepeatID.txt for the WG's convenience.

Reviewing that discussion, I'm actually not impressed.  There were a 
few -1's but very few actual technical arguments about why this 
shouldn't be done.  The most common was "Software will screw this up".  
On reflection, I don't believe that.  You have a bunch of Entries, some 
of them have the same ID and are distinguished by datestamp.  Some 
software will show the latest, some will show all of them, the good 
software will allow switching back and forth.  Doesn't seem like rocket 
science to me.

So here's how I see it: there are plausible use cases for doing this, 
and one of the leading really large-scale implementors in the space 
(PubSub) wants to do this right now.  Bob's been making strong claims 
about not being able to use Atom if this restriction remains in place.

I believe strongly that if there's something that implementors want to 
do, standards shouldn't get in the way unless there's real 
interoperability damage.  I'm certainly prepared to believe that this 
could cause interoperability damage, but to date I haven't seen any 
convincing arguments that it will.  I think that if we nonetheless 
forbid it, people who want to do this will (a) use RSS instead of Atom, 
(b) cook up horrible kludges, or (c) ignore us and just do it.

So my best estimate is that the cost of allowing dupes is probably much 
lower than the cost of forbidding them.

Finally, our charter does say that we're also supposed to specify how 
you'd go about archiving feeds, and AllowDuplicateIDs makes this 
trivial.  I looked around and failed to find how we claimed we were 
going to do that while still forbidding duplicates, but it's possible I 
missed that.

3. Alternate Paces

I didn't want to just revive PaceRepeatIdInDocument, because it used 
the word "version" in what I thought was kind of a sloppy way, and 
because it wasn't current against format-08.  I don't like either 
PaceDuplicateIDWithSource or ...WithSource2, they are complicated and 
don't really meet PubSub's needs anyhow.  So I'm strongly -1 on both of 
those.  Yes, that means that if this Pace fails, we'll allow no 
duplicates at all.  I prefer either "dupes OK" or "no dupes" to "dupes 
OK in the following circumstances"; cleaner.

4. Details

Section 4.1.2 of format-08 says that atom:entry "represents an 
individual entry".  The Pace says that if you have dupes, they 
"represent the same entry", which I think is consistent with both the 
letter and spirit of 4.1.2.

The Pace discourages duplicate timestamps without resorting to MUST 
language, because accidents can happen; this allows software to throw 
such entries on the floor while positively encouraging noisy 
complaining.  On the other hand, if the WG wanted either to insist on a 
MUST here or remove the discouragement altogether I could live with 
that.

Finally, it makes it clear that if there are entries with duplicate 
atom:id, software is free to display all or a subset, and calls out the 
likely common case where you discard all but the most recent.  If I 
were Brent Simmons or equivalent, I'd be coding up a button where you 
can arrange to show them all or just one.

</co-chair-hat>

---

From: Tim Bray <[email-masked]>
Date: Wed, 04 May 2005 22:05:10 -0700

> Here's a stream of stock-market quotes.

[snicker] I left the ID's out of the entries in the example.  Imagine 
that each one has
  <id>urn:uuid:1335c695-cfb8-4ebb-aaaa-80da344efa6a</id>

-Tim

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 09:01:48 +0200

Tonight something incredible happened to me. You won't believe it. I  
was walking
back from the pubs when I got snapped by a passing space ships full
of hyper advanced aliens. They did various experiments on me, and  
cloned me 1000
times. It is terrible. I just don't know what to do.

I suppose that I means am +1000 on this now.

:-) That's consensus, I am sure.

Henry
http://bblfish.net/blog/

On 5 May 2005, at 06:02, Tim Bray wrote:
> This Pace was motivated by a talk I had with Bob Wyman today about  
> the problems the synthofeed-generator community has.
>
> Summary:
> describes an earthquake and they keep re-issuing it as new info  
> about strength/location comes in.
>
> You could argue that in some cases, these are representations of  
> the Web resources identified by the atom:id URI, but I don't think  
> we need to say that explicitly.
>
> Yes, you could think of alternate ways of representing stock quotes  
> or any of the other use-cases but this is simple and direct and  
> idiomatic.
>
> 2. Pro and Contra
>
> Given that I issued the consensus call rejecting the last attempt  
> to do this, which was  PaceRepeatIdInDocument, I felt nervous about  
> that one, which I extracted and placed at http://www.tbray.org/tmp/ 
> RepeatID.txt for the WG's convenience.
>
> Reviewing that discussion, I'm actually not impressed.  There were  
> a few -1's but very few actual technical arguments about why this  
> shouldn't be done.  The most common was "Software will screw this  
> up".  On reflection, I don't believe that.  You have a bunch of  
> Entries, some of them have the same ID and are distinguished by  
> datestamp.  Some software will show the latest, some will show all  
> of them, the good software will allow switching back and forth.   
> Doesn't seem like rocket science to me.
>
> So here's how I see it: there are plausible use cases for doing  
> this, and one of the leading really large-scale implementors in the  
> space (PubSub) wants to do this right now.  Bob's been making  
> strong claims about not being able to use Atom if this restriction  
> remains in place.
>
> I believe strongly that if there's something that implementors want  
> to do, standards shouldn't get in the way unless there's real  
> interoperability damage.  I'm certainly prepared to believe that  
> this could cause interoperability damage, but to date I haven't  
> seen any convincing arguments that it will.  I think that if we  
> nonetheless forbid it, people who want to do this will (a) use RSS  
> instead of Atom, (b) cook up horrible kludges, or (c) ignore us and  
> just do it.
>
> So my best estimate is that the cost of allowing dupes is probably  
> much lower than the cost of forbidding them.
>
> Finally, our charter does say that we're also supposed to specify  
> how you'd go about archiving feeds, and AllowDuplicateIDs makes  
> this trivial.  I looked around and failed to find how we claimed we  
> were going to do that while still forbidding duplicates, but it's  
> possible I missed that.
>
> 3. Alternate Paces
>
> I didn't want to just revive PaceRepeatIdInDocument, because it  
> used the word "version" in what I thought was kind of a sloppy way,  
> and because it wasn't current against format-08.  I don't like  
> either PaceDuplicateIDWithSource or ...WithSource2, they are  
> complicated and don't really meet PubSub's needs anyhow.  So I'm  
> strongly -1 on both of those.  Yes, that means that if this Pace  
> fails, we'll allow no duplicates at all.  I prefer either "dupes  
> OK" or "no dupes" to "dupes OK in the following circumstances";  
> cleaner.
>
> 4. Details
>
> "represent the same entry", which I think is consistent with both  
> the letter and spirit of 4.1.2.
>
> language, because accidents can happen; this allows software to  
> throw such entries on the floor while positively encouraging noisy  
> complaining.  On the other hand, if the WG wanted either to insist  
> on a MUST here or remove the discouragement altogether I could live  
> with that.
>
> atom:id, software is free to display all or a subset, and calls out  
> the likely common case where you discard all but the most recent.   
> If I were Brent Simmons or equivalent, I'd be coding up a button  
> where you can arrange to show them all or just one.
>
> </co-chair-hat>
>

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 09:52:46 +0100

>   <content>Bid: 25.10 Ask: 25.15 Last: 25.10</content></item>

Tim, model this as a blog first. Is it:
a) One entry that's being updated?
b) Hourly new postings with the latest price?

See, I think it's b). Which under any sensible circumstance would  
count as new entries, and therefoe get new ids. You're trying to use  
atom:id as a category system here. Let's say I post a new picture of  
my cat every day. Should all my blog entries have the same id?

Technical problems:
The problem multiple ids is that we don't have a date element that  
provides a definitive answer to the question, "What is the current  
version?", which 99% of the time is all an aggregator needs. For  
example, what happens if I retract an update to an entry, and  
presumably roll back atom:updated? The new version stays? If so, the  
spec of atom:updated needs changing.

I see you have the constraint "Their atom:updated timestamps SHOULD  
be different, and processing software SHOULD regard entries with  
duplicate atom:id and atom:updated values as evidence of an error in  
the feed generation". Does this apply temporally as well as  
spatially? For example, if the content changes the second time I load  
something, but the atom:updated doesn't, is that an error?

Again, atom:updated falls short for this purpose.

Finally, at pubsub, what happens when they download an entry from one  
feed, then the user edits it, but doesn't modify atom:updated, then  
they download the new entry from a second feed associated with the  
site. Different content, identical atom:ids, identical atom:updated  
=> Invalid feed. They're not in any better position than they were  
before. This doesn't even solve the problem it's meant to.

"If an Atom Feed Document contains multiple entries with the same  
atom:id, software MAY choose to display all of them or some subset of  
them"

What does this even mean, other than "atom:id is meaningless, ignore  
it"?

> I looked around and failed to find how we claimed we were going to  
> do that while still forbidding duplicates, but it's possible I  
> missed that.

Duplicate ids is a constraint of the atom:feed element. Use a  
different top level element, atom:archive, for archives.

Graham

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 12:36:33 +0200

I hope it won't be thought rude for me to answer your questions to Tim.

> On 5 May 2005, at 5:02 am, Tim Bray wrote:

[I have added the id's tim mentioned he forgot]

> b) Hourly new postings with the latest price?

Given that the ids are the same it is now clear that we have  
situation a)

> count as new entries, and therefoe get new ids. You're trying to  
> use atom:id as a category system here.

No, this is just the way resources on the internet work. If you go to  
<http://google.com/>
you will get a different web page every day. A resource can have  
different representation
at different times. Google could of course architecture its web site  
differently and have
<http://google.com/> be simply a redirect to a dated resource that  
would be unchanging.
Both work.

> Let's say I post a new picture of my cat every day. Should all my  
> blog entries have the same id?

If all your cat blog entries had the same id, and you posted a new  
picture of your cat every
day, then you should expect that some aggregators or clients might  
dump all but the latest
version of your entry.

So it depends on what you want.

   If you want a feed of how your cat changed, and you want to make  
sure that people will be
  able to see all the changes to your cat, then you would have a  
different entry for
each of the cat states, and each of these would have their own  
"alternate" link.

   If you want an entry about what you think of your cat today, or  
what your cat looks like
today, then you would have one entry with the same id changing on a  
daily basis. Aggregators
could choose to keep the older versions, or they could choose to  
discard them.

> version?", which 99% of the time is all an aggregator needs.

You can never know about any resource on the net what the "current  
version" is. This is due
to limits such as the speed of light, the speed at which data can  
travel through the pipes
across the world, etc...

But it does not matter. All you may be interested in at any point in  
time is what is the
latest version that *you* have available. You can't do better than  
that. So if you get a
feed with two entries with the same id, you just look at the time  
stamp and keep the latest.
If you find the same id in another trusted feed, you make the same  
comparison.

> For example, what happens if I retract an update to an entry, and  
> presumably roll back atom:updated? The new version stays? If so,  
> the spec of atom:updated needs changing.

There are two situations here:
   A. You remove the later entry representation that you placed in  
your feed. You can do this,
    but it won't stop people who have already retrieved your feed  
from having received the old
    representation of the feed, with the non retracted entry.  
Remember that the internet has a
    memory, both long term [1] and short term. For example all the  
caches in the world that this
    representation may have travelled through may also  contain that  
representation. The more
    intelligent caches (such as the one in an aggregator) may on  
later retrieving your altered
    feed and comparing the entry therein with the one  they have in  
memory, decide to keep the
    one they have in memory, since that is a later version of your  
entry.
   B. You make clear that your retraction is an event, and so you add  
a new entry with that id
    (you may, but need not, remove the old entry representation (the  
<entry>....</entry>)) and
    with a new time stamp, but with the old content.

I suggest that B. would be the more honest and less confusing option  
to the readers of your feed.

> duplicate atom:id and atom:updated values as evidence of an error  
> in the feed generation". Does this apply temporally as well as  
> spatially? For example, if the content changes the second time I  
> load something, but the atom:updated doesn't, is that an error?

As I see, Tim's language is currently restricted to what happens with  
two entries with the same id
in the same feed document. What happens across feed documents is not  
defined here.

I myself think that having entries with different contents with the  
same id across feeds, would be confusing to receiving software and  
would be close to being an error. Ie. if you do that then you should  
not be surprised if your clients behave erratically, either ignoring  
the second version,
or flagging an error, or keeping the second entry over the first.

But then this would be the case for any similar situation. Imagine  
that your bank publishes xml
of the history of your accounts, and changes the content for a  
particular month, without notifying
you that anything has changed. I think this would be a cause for  
concern, and would justify
you looking into it.

In any case this is something we may or may not define. It is not a  
problem with PaceAllowDuplicateIDs. In fact you have just uncovered  
something that was problematic before.

> Again, atom:updated falls short for this purpose.

No. You have just shown that if you make consequential changes to an  
entry and don't change
your atom:updated field, you will end up with interoperability issues.

> Finally, at pubsub, what happens when they download an entry from  
> one feed, then the user edits it, but doesn't modify atom:updated,

Either the change they made is "significant" or it is not. If it is a  
significant change then
by not changing the atom:updated field the user will have done  
something other than what he thought
he was doing. For by not changing the date he is allowing receiving  
software to decide by themselves
whether they wish to keep or drop the change. If it is not a  
significant change, then the receiving
software won't be doing anything problematic by either dropping the  
later version received or keeping it.

> then they download the new entry from a second feed associated with  
> the site. Different content, identical atom:ids, identical  
> atom:updated => Invalid feed. They're not in any better position  
> than they were before. This doesn't even solve the problem it's  
> meant to.
>
> atom:id, software MAY choose to display all of them or some subset  
> of them"
>
> What does this even mean, other than "atom:id is meaningless,  
> ignore it"?

If you try out the latest version of BlogEd you can see for yourself.  
Though BlogEd is a blog
editor it keeps all the changes you make to your entry in its  
database allowing you to visit
previous versions.

It still in beta and buggy, but that aspect of the functionality  
works well.
Instructions for installing with jnlp are available here:
     http://blogs.sun.com/bblfish

So that would be one way to view the previous version of an entry.  
There will be many others.
Many readers will be happy to drop the older versions, but many will  
be happy to keep them.

> different top level element, atom:archive, for archives.

Well that seems like a very complicated way of solving a problem  
where allowing entries with duplicate ids in a feed document from the  
start would be much simpler. If you are going to
allow <archive> feeds to keep duplicates then why not just allow   
<feeds> and be done with it?

Henry Story
http://bblfish.net/blog/

[1] http://bblfish.net/blog/page5.html#44

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 12:32:45 +0100

> Given that the ids are the same it is now clear that we have  

I said "first", before we decide what ids we should use. If created  
as a blog, Tim's stock quotes would make most sense (to me) posted as  
hourly new entries. Ergo, they should each have different ids. Again,  
atom:id is not a category system.

> Either the change they made is "significant" or it is not. If it is  
> a significant change then

atom:updated is used by the publisher to show what they consider a  
significant change. The user, on the other hand, wants to see the  
latest version, reliably, even if the publisher disagrees that the  
change was significant. This is the core problem with Tim's proposal.  
There is no way to create an aggregator that works in the way the  
user expects.

I am lying down in the road here, as Tim would say.

> where allowing entries with duplicate ids in a feed document from  
> the start would be much simpler. If you are going to

Because feeds are feeds and archives are archives? They have  
different audiences and different uses and different requirements.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Thu, 05 May 2005 23:26:34 +1000

> There is no way to create an aggregator that works in the way the

perhaps we needed atom:modified after all :-(

> different audiences and different uses and different requirements.

And what about the use case of a wiki's RecentChanges log? Each entry refers
to a specific page, and there may be multiple such entries for each page as
it gets rapidly edited ... and wiki folks have found it important to be able
to monitor all change events.

I sure hope we don't have to define yet another atom document root element
(eg. <wikilog>). That sounds like such a hack.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 09:41:47 -0400

> to monitor all change events.

I'm much more sympathetic to the aggregate feed problem of multiple
IDs. People advocating this type of thing seem to think the default
action should be grouping, so they want to use the same ID. I think
that's a bad idea, and there are plenty of other ways to indicate the
fundamental sameness of entries. For example, NewsML URNs have a
NewsItemID and a RevisionID, which would allow smart aggregators to
group the entries without violating Atom's constraint.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 14:55:23 +0100

> perhaps we needed atom:modified after all :-(

Yes we do, if we want to go down this route. I suggest appending the  
current time (or for old versions, the last time that version was  
current) at the source.

> to monitor all change events.

Each log entry is an entry in itself, with its own id. That seems a  
far better functional parallel to the basic blog feed. As with the  
share price example, the topic of the entry (the company, or the wiki  
page) is far more analogous to a category that the entry belongs to,  
than to an its identity. Everyone stop trying to use ids as a  
category system.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Fri, 06 May 2005 00:23:55 +1000

On 5/5/05 11:55 PM, "Graham" <[email-masked]> wrote:

> Each log entry is an entry in itself, with its own id.

Sorry, that makes as much sense as changing the id for a blog entry if that
blog entry is updated.

The functional parallel is wiki-page = blog-entry, and if a blog-entry is
updated then that is reflected in the feed as an updated entry - with the
same id.

e.

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 16:32:50 +0200

On 5 May 2005, at 15:55, Graham wrote:
> Yes we do, if we want to go down this route. I suggest appending  
> the current time (or for old versions, the last time that version  
> was current) at the source.

Sorry I don't understand why we need atom:modified.

> far better functional parallel to the basic blog feed.

As I explained in my lengthy reply to your lengthy post, I think one  
should be able to do either.
Each way has its advantages and disadvantages. Let the publisher  
decide which mechanism to use.

> As with the share price example, the topic of the entry (the  
> company, or the wiki page) is far more analogous to a category that  
> the entry belongs to, than to an its identity.

Again let the publisher choose what the identity criterion of his  
objects are. Some will stick
some will not. But it is not up to us to decide for our users.

Since it does not cause any interoperability issues, what's the problem?

> Everyone stop trying to use ids as a category system.

I don't think that one would be using ids as a category system. If  
you go to
<http://google.com> you get todays front page. Tomorrow you get  
tomorrows front page.
What's the problem? Is <http://google.com> a hidden category system?

Henry Story
http://bblfish.net/blog/

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 10:34:32 -0400

> Sorry, that makes as much sense as changing the id for a blog entry if that

Graham's got it exactly right. 
 
> updated then that is reflected in the feed as an updated entry - with the

That's right, that is the functional parallel. No software I know of 
shows both revisions of the entry in the feed when it's updated. If
you are syndicating wiki changes, part of each entry is the diff and
revision id--each revision is a unique thing.

Another analogous use case would be a feed watching a certain file in
CVS. Every entry would be about the same file, but each would have its
own atom:id.

Once again, there remains a downstream problem for PubSub, etc. 

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 15:38:45 +0100

On 5 May 2005, at 3:32 pm, Henry Story wrote:

> As I explained in my lengthy reply to your lengthy post, I think  
> one should be able to do either.

Well please flag it so that I can provide a consistent user interface  
to people's whims?

> Since it does not cause any interoperability issues, what's the  

I have to come up with a new way to recognise and interpret such  
feeds where an entry (as defined by its id) isn't an entry but a feed  
of different entries.

> What's the problem? Is <http://google.com> a hidden category system?

Charter: "Atom defines a feed format for representing resources such  
as Weblogs, online journals, Wikis,
and similar content"

Atom is not a replacement for HTTP. Google.com is a web page, not  
"similar content". It's not relevant here.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Thu, 5 May 2005 08:44:07 -0600

If we accept this Pace, are we going to do anything to address the DOS 
issue for aggregated feeds?

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 15:45:59 +0100

> Sorry, that makes as much sense as changing the id for a blog entry  

Have a look here:
http://en.wikipedia.org/w/index.php?title=Main_Page&action=history

There you have a reverse chrono list, each with an author, date, and  
summary. Looks an awful lot like each one is an entry to me.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Fri, 06 May 2005 01:09:42 +1000

> Sorry I don't understand why we need atom:modified.

Graham suggested it : a reliable way for an aggregator to discern the latest
version of an entry.

> There is no way to create an aggregator that works in the way the

... no way, that is, unless we have atom:modified making each same-id entry
distinct, and not just distinct but also time-ordered and time-distanced (an
advantage over just using something similar to the NewsML RevisionID
mechanism).

e.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 06 May 2005 01:15:24 +1000

> summary. Looks an awful lot like each one is an entry to me.

and looks to me like a stream of meta-data concerning the one entry to me.

and not distinct and separable entries like you'd find in your every day
blog.

Henry has the right idea -- the spec should allow both kinds, rather than
trying to shoe-horn everything into the one viewpoint of what is an entry.

e.

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 17:22:32 +0200

On 5 May 2005, at 16:38, Graham wrote:
> Well please flag it so that I can provide a consistent user  
> interface to people's whims?

What is the problem with the user interface that you have exactly? I  
have pointed you to
BlogEd that keeps a history of all the changes to an entry. Try it out:
     http://blogs.sun.com/roller/page/bblfish/
Its open source, so you can also copy the code.

If you don't want to keep a history of the entries all you need to do  
is drop all but the
latest entry with the same id. There is nothing more to it. Just show  
the user the last
one you came across.

> feeds where an entry (as defined by its id) isn't an entry but a  
> feed of different entries.

No you don't. Just drop the old ones, if you don't care about the  
history. Really simple.
As Tim Bray's text says

  [[
    software MAY choose to display all of them or some subset of them
  ]]

So just drop the older versions.

> Charter: "Atom defines a feed format for representing resources  
> such as Weblogs, online journals, Wikis,
> and similar content"

yes, and it must also allow the representation of

[[
    * a complete archive of all entries in a feed
]]

This proposal permits this, and it does not harm anyone else.

> "similar content". It's not relevant here.

I don't know where you get the idea that I said atom is a replacement  
for HTTP. Take a breath
perhaps and relax before you answer.

---

From: David M Johnson <[email-masked]>
Date: Thu, 05 May 2005 11:27:56 -0400

I'm -1 on PaceAllowDuplicateIDs

Reasons:

1) We're supposed to be standardizing current practice not inventing 
new things. Current best practice is to have unique IDs and current 
software (e.g. Javablogs.com) is predicated on this practice. I know, 
this practice is not followed widely enough, but that is another 
matter.

2) I think it is *much* more useful to think of an Atom Entry as an 
event that occurred at a specific time. Typically, an event is the 
publication of an article or blog entry on the web. For example:

    event: CNET published article
    subject: CNET
    object: article

But an event it could also represent other events.

    event: delivery van delivers package
    subject: delivery van
    object: package

    event: alarm system sends warning
    subject: alarm system
    object: warning

    event: server sends load warning
    subject: server
    object: load warning

If you think of Atom Entries as events, then it makes sense to consider 
the Atom Entry ID to be the ID of the event, not the ID of the subject 
or object of the event. Events are unique (you can't have more than one 
version of an event) and can be assigned GUIDs and therefore you cannot 
have more than one entry with the same ID.

In the case of earthquake data, each new data report is a new event.

    event: agency reports earthquake data
    subject: agency
    object: earthquake data

The ID is the ID of the "data reported" event not the ID of the 
earthquake.

We don't know what subjects and objects people are going to use in the 
future, so we can't specify Atom elements or IDs for subjects and 
objects -- that's what extensions are for. If you want to create a feed 
to syndicate information about earthquakes, then you introduce an 
extension for uniquely identifying earthquakes. The same goes for 
earthquakes.

- Dave

On May 5, 2005, at 12:02 AM, Tim Bray wrote:

> Given that I issued the consensus call rejecting the last attempt to 
> do this, which was  PaceRepeatIdInDocument, I felt nervous about 
>  On reflection, I don't believe that.  You have a bunch of Entries, 
> some of them have the same ID and are distinguished by datestamp.  
> Some software will show the latest, some will show all of them, the 
> good software will allow switching back and forth.  Doesn't seem like 
> rocket science to me.
>
> forbid it, people who want to do this will (a) use RSS instead of 
> Atom, (b) cook up horrible kludges, or (c) ignore us and just do it.
>
> going to do that while still forbidding duplicates, but it's possible 
> I missed that.
>
> 3. Alternate Paces
>
> don't really meet PubSub's needs anyhow.  So I'm strongly -1 on both 
> of those.  Yes, that means that if this Pace fails, we'll allow no 
> complaining.  On the other hand, if the WG wanted either to insist on 
> a MUST here or remove the discouragement altogether I could live with 
> that.
>
> the likely common case where you discard all but the most recent.  If 
> I were Brent Simmons or equivalent, I'd be coding up a button where 
> you can arrange to show them all or just one.
>
> </co-chair-hat>
>

---

From: Antone Roundy <[email-masked]>
Date: Thu, 5 May 2005 09:34:57 -0600

> trying to shoe-horn everything into the one viewpoint of what is an 
+1 -- allow the publisher to decide which model fits their intent.

---

From: Dave Johnson <[email-masked]>
Date: Thu, 5 May 2005 11:38:54 -0400

Immediately after sending this message, I had a rush  of second 
thoughts.

My point #2 is not very well thought out. I think it applies for things 
like earthquake data, but when Atom feeds represent blog entries or 
articles (in an archive or an Atom Protocol feed) the  ID represents 
the article not an event in the blog entry's life.  So, you can 
discount my second reason against the pace.

- Dave

On May 5, 2005, at 11:27 AM, David M Johnson wrote:

> If you think of Atom Entries as events, then it makes sense to 
> consider the Atom Entry ID to be the ID of the event, not the ID of 
> the subject or object of the event. Events are unique (you can't have 
> more than one version of an event) and can be assigned GUIDs and 
> therefore you cannot have more than one entry with the same ID.
>
> objects -- that's what extensions are for. If you want to create a 
> feed to syndicate information about earthquakes, then you introduce an 
>> Web resources identified by the atom:id URI, but I don't think we 
>> need to say that explicitly.
>>
>> datestamp.  Some software will show the latest, some will show all of 
>> them, the good software will allow switching back and forth.  Doesn't 
>> seem like rocket science to me.
>>
>> duplicates at all.  I prefer either "dupes OK" or "no dupes" to 
>> "dupes OK in the following circumstances"; cleaner.
>>
>> 4. Details
>>

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 16:53:46 +0100

On 5 May 2005, at 4:22 pm, Henry Story wrote:

> If you don't want to keep a history of the entries all you need to  
> do is drop all but the
> latest entry with the same id. There is nothing more to it. Just  
> show the user the last
> one you came across.

But, if we follow Eric's model of how a wiki changelog should be  
defined, I'll be missing entries in the log, because several  
different entries have the same id. Ergo, the user interface and data  
model for the new type of feed this proposal permits is very different.

> This proposal permits this, and it does not harm anyone else.

It harms everyone, by allowing a second, unrelated data model in Atom  
feeds. They may not be posting today, but I assure you, when other  
aggregator authors get the first user complaints about how Eric's  
wiki log displays incompletely in their program, they'll forgive Dave  
Winer everything.

Graham

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 18:11:07 +0200

Hi Dave,

      nice to see you participate here. I understand your points, and  
I myself thought the
way you did for a while.

[Oops, I see now that you have retracted your point. Oh well. I had  
already started writing
the following]

> I'm -1 on PaceAllowDuplicateIDs

Please consider the following points before you vote.

> Reasons:
>
> 1) We're supposed to be standardizing current practice not  
> inventing new things. Current best practice is to have unique IDs  
> and current software (e.g. Javablogs.com) is predicated on this  
> practice. I know, this practice is not followed widely enough, but  
> that is another matter.

Atom is standardizing current practice, but it is also adding some  
features. For example name
spaces and ids. The atom charter also requires us to allow archives

[[

Graham himself thinks that archives are possible, since he supports  
the use of an
<archive> head element.

> the subject or object of the event.

You are right. There are two types of objects that we need to think  
about:
    A- the event/state of a resource at a particular time
    B- the thing that makes these different states the state of the  
same thing

Clearly we need (B) or else all the talk about an entry changing over  
time (atom:updated)
would not make sense.

So let us start off, as I did a long time ago, by thinking that the  
the id of an entry
uniquely identifies the event/state of the entry. For every id there  
can be only one and
only one "<entry>....</entry>" representation. That id is that  
representation. It is, if you
wish, the name of a state of something else... and that would be?

I think it is clear that one of the roles of the id is to make it  
possible for an
entry to be moved from one web site to another, so that if your blog  
service provider
lets you down, you can still refer to the entry even when you have  
moved it to a
different "alternate" position. Graham has made such a point quite  
often. Entries it
has often been said can change, but the id remains the same. I think  
this is clearly
the consensus on this list. So the id URI is what identifies the  
different
"<entry>...</entry>" representations as being representations of the  
same thing.

> Events are unique (you can't have more than one version of an  
> event) and can be assigned GUIDs and therefore you cannot have more  
> than one entry with the same ID.

yes. But I don't think that this is the consensus on this group. The  
good thing is that
you can achieve the same identification of a state through the  
combination of the id and the
modification time.

[here I noticed that you had changed your mind, anyway. I think I had  
exactly the same
thought as you did when I first started thinking about this. ]

> We don't know what subjects and objects people are going to use in  
> the future, so we can't specify Atom elements or IDs for subjects  
> and objects -- that's what extensions are for. If you want to  
> create a feed to syndicate information about earthquakes, then you  
> introduce an extension for uniquely identifying earthquakes. The  
> same goes for earthquakes.
>
> - Dave
>
>

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 18:38:08 +0200

On 5 May 2005, at 17:53, Graham wrote:
> different entries have the same id. Ergo, the user interface and  
> data model for the new type of feed this proposal permits is very  
> different.

If your tool (Is it Shrook2? [1]) only shows people the latest  
version available to you of
an entry, then by showing them only the latest version, Shrook2 will  
be giving the user what
he is expecting.

When your news reader currently reads feeds on the internet what does  
it do
with changed entries? Either it keeps the older version around, for  
the user to browse, or it
does not. If your users don't mind you throwing away the older  
versions of an entry, then
they won't mind you throwing away the older versions of the above  
entries either. There is no
difference in the behavior between allowing changed entries across  
feed documents and changed
entries inside a feed document. People who place two entries with the  
same id inside a feed
document should be aware that tools like yours will have the behavior  
they do, and that this is
ok.

Other people may be interested in looking at things historically.  
They will get a historical
viewer and be happy with it.

I think the current proposal is good exactly because it allows the  
wiki people to express
what they want to express correctly. Namely how their wiki entry is  
changing over time.

> It harms everyone, by allowing a second, unrelated data model in  
> Atom feeds. They may not be posting today, but I assure you, when  
> other aggregator authors get the first user complaints about how  
> Eric's wiki log displays incompletely in their program, they'll  
> forgive Dave Winer everything.

Again, has anyone yet complained to you that you have not kept a  
historical and browse-able track
record of how the entries Shrook2  is looking at have changed over  
time? Clearly they could,
as you sometimes let them know that an entry that they already have  
read has been updated. They
could ask you what the changes were, no? How it changed, etc.

If your users don't care that much about the history of an entry,  
then you can dump all but the
latest entry. Or you could just keep the last two entries, so that  
you can show them a diff.

> Graham

HJStory
http://bblfish.net/blog/

[1] http://www.fondantfancies.com/apps/shrook/

---

From: Eric Scheid <[email-masked]>
Date: Fri, 06 May 2005 02:38:38 +1000

> wiki log displays incompletely in their program, they'll forgive Dave

Many wiki's offer options in displaying their change log with either most
recent changes only, or all changes. Both models are commonly supported
because some people want to see notifications of all changes, while others
just want to see the most recent change. That is part of wiki culture, all
the way back to ward's wiki.

It wouldn't be surprising to find the same options made available for wiki
logs in rss. Hey, here's one right now....

    http://www.intertwingly.net/wiki/pie/RecentChanges?action=rss_rc

Apparently, if you add an "unique=1" URL parameter you get a list of changes
where page names are unique, i.e. where only the latest change of each page
is reflected.

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 5 May 2005 11:20:19 -0600

> issue for aggregated feeds?

Bob, if I may direct a few question to you, since you have the most 
experience with this issue: if PaceAllowDuplicateIDs is adopted, how 
would you anticipate that PubSub would go about handling entries with 
the same atom:id coming from different feeds?  What if each appears to 
be claiming to be the original feed for the entry?  What if both are 
getting aggregated into the same feed, but your system doesn't think 
they're really the same entry?

I'm in favor of the Pace, as far as it goes, but was surprised to see 
that it doesn't talk about these issues, given that it was motivated by 
a conversation with you.

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 18:23:31 +0100

> the way back to ward's wiki.

OK that makes sense. I still think it's the wrong way to model a  
change log as a feed.

My other two criticisms still stand:

"atom:updated is used by the publisher to show what they consider a  
significant change. The user, on the other hand, probably wants to  
see the latest version, reliably, even if the publisher disagrees  
that the change was significant. This is the core problem with Tim's  
proposal. There is no way to create an aggregator that works in the  
way the user expects."

"Finally, at pubsub, what happens when they download an entry from  
one feed, then the user edits it, but doesn't modify atom:updated,  
then they download the new entry from a second feed associated with  
the site? Different content, identical atom:ids, identical  
atom:updated => Invalid feed. They're not in any better position than  
they were before. This doesn't even solve the problem it's meant to."

Basically, atom:updated doesn't properly differentiate versions, and  
the way atom:updated is being used by the proposal doesn't gel with  
the actual spec of the element.

Graham

---

From: Henry Story <[email-masked]>
Date: Thu, 5 May 2005 19:52:28 +0200

> OK that makes sense. I still think it's the wrong way to model a  

Cool. Rational argument does sometimes work :-)

> My other two criticisms still stand:

What was wrong with the arguments I gave?

> that the change was significant. This is the core problem with  
> Tim's proposal. There is no way to create an aggregator that works  
> in the way the user expects."

I think this is relatively simple. If the publisher publishes a feed  
document with two entries containing the same id and the same  
atom:updated timestamp then he is claiming that there are no  
significant changes between them. In fact the same is true if he  
publishes those two entries in two different feed documents. So there  
really is no problem here that is particular to PaceAllowDuplicateIDs.

If the feed reader wants reliability he can't get more reliability by  
making the spec tighter
than the feed producer is able to give. If the feed producer is  
unreliable, then nothing in the
spec can change that.

The feed producer must understand that by creating feeds where the  
above described situation is
true will lead to erratic behavior. If there is a significant  
difference between those entries
then he had better change the time stamp. Otherwise his unreliable  
behavior will create unreliable
effects. Nothing new here.

> meant to."

I imagine this is simple, but I will leave the full details for Bob  
to answer. My guess is that
if Bob comes across the above situation, then he will be confronted  
by a situation where he has
according to the publisher two entries that are not significantly  
different. He can therefore choose
between them randomly, and just add one of them. The publisher after  
all thinks that there are
no significant differences between them. If the initial publisher  
thought that there were significant differences between these  
entries, then he should have given them different time
stamps.

> Basically, atom:updated doesn't properly differentiate versions,  
> and the way atom:updated is being used by the proposal doesn't gel  
> with the actual spec of the element.

I think the above argument shows that there is in fact nothing wrong  
with atom:updated.
We just have to think in terms of interoperability and not in terms  
of Platonic forms.

Henry Story
http://bblfish.net/blog/

---

From: [email-masked] (John Panzer)
Date: Thu, 05 May 2005 11:01:29 -0700

> proposal. There is no way to create an aggregator that works in the  

Just a thought:  On the other hand, perhaps this is an opportunity to 
operationally define "significant change":  A change which results in a 
new version being exposed on one's feed.  If you think your users would 
care about seeing the change, then change the atom:updated field and 
'republish' by adding to the feed.  If not, just change your content and 
don't republish.

Examples of this might include:  Fixing irrelevant typos.  Changing 
character set encodings.  Changing formatting to match a new style guide.

-John

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 06 May 2005 09:30:58 +0100

> group the entries without violating Atom's constraint.

Then you have two ways of indicating fundamental sameness of entries, 
one for when the same entry appears multiple times in a feed, and one 
for everything else.

Back to basics then. Does anyone remember why having the same id in a 
feed is a bad idea?

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 06 May 2005 10:17:30 +0100

Dave Johnson wrote:
> 
> Immediately after sending this message, I had a rush  of second thoughts.
> 
> articles (in an archive or an Atom Protocol feed) the  ID represents the 
> article not an event in the blog entry's life.  So, you can discount my 
> second reason against the pace.

Good, because not everyone would agree that's what's being modeled. Now 
I also think your 1) starts to fall away as well because 2) no longer 
holds. That is, some of the argument for "Current best practice" you're 
talking about (you sure about "best" in there? ;) is predicated on 
entries being like events. Aggregators tend, or would like, to treat 
entries as singular happenings. Finally some events are not easily 
modeled in the discrete way you're talking about (in turn some of that 
comes down to how you model time), I don't think we have to worry about 
those here.

Put it this way, under either "this is an event stream" or "this is a 
stream of entries", having multiple entries in a single feed is not an 
unreasonable request. We came up with the id approach to allow people to 
zero in on duplicates; that's the primary case. We did that without 
really articulating what an entry stands for, some effort was done 
post-hoc, but it doesn't seem to have made it as spec text. Consider. Is 
the XML entry in a feed a representation of an entry, a la REST? If so, 
does the id identify the representation or the entry? If the id 
identifies the entry representation, how (or should) we identify the 
entry? If the id identifies the entry, how (or need) we identify the 
representation?

Those are just some of the questions, we could ask.  We could then ask 
the whole set over regarding what a feed is, as that has a bearing too.

I've said this before - the technical problem we have is that we can't 
distinguish between a buggy feed with the same ids and an aggregate feed 
with the same ids under the current spec. Because you can't have it both 
ways, that rationale should have been provided in the spec. It's an 
architectural constraint - you can not say this with your feed because 
we can't make sense of it -  done, not to preserve some notion of 
identity we have here, but to allow people to drop duplicates and 
normalize their streams. The downside is that 1) some people do want to 
aggregate versions of an entry in a single feed, which presumably have 
the same id, so "they or others can say, these are all of the same 
thing", 2) some people do re-edit their entries or edit their entry 
dates around so the entry reappears with updated content. Bray does this 
with his Sunday server logs and no-one convinced me it's not equally as 
questionable an approach at some level as allow duplicate ids, or 
munging URLs the way ad people do - who cares as long as it gets into 
people's clients?

And it's clear now, that ids don't solve "the get rid of all those 
duplicates problem", dates are required also, to cater for cases where 
someone updates the entry, but we don't want people to miss that because 
of over-eager reaping on the clients.

It's a mess, that's our fault. As a first step we need to be able to say 
what's being identified. If we decide we don't care about that, we just 
want to illegalise duplicates, then maybe ids were not the right idea to 
begin with.

cheers
Bill

---

From: Dave Johnson <[email-masked]>
Date: Fri, 6 May 2005 09:10:50 -0400

On May 6, 2005, at 5:17 AM, Bill de hÓra wrote:

>> My point #2 is not very well thought out. I think it applies for 
>> things like earthquake data, but when Atom feeds represent blog 
>> entries or articles (in an archive or an Atom Protocol feed) the  ID 
>> represents the article not an event in the blog entry's life.  So, 
>> you can discount my second reason against the pace.
>
> Good, because not everyone would agree that's what's being modeled. 
> Now I also think your 1) starts to fall away as well because 2) no 
> longer holds. That is, some of the argument for "Current best 
> practice" you're talking about (you sure about "best" in there? ;) is 
> predicated on entries being like events. Aggregators tend, or would 
> like, to treat entries as singular happenings. Finally some events are 
> not easily modeled in the discrete way you're talking about (in turn 
> some of that comes down to how you model time), I don't think we have 
> to worry about those here.

Yes, I think both of my arguments fail to hold and I no longer have a 
real objection to duplicates. Allowing duplicates gives feed produces 
to model events or other objects (versioned documents in a wiki) as 
they wish. Like you, I wonder "Does anyone remember why having the same 
id in a feed is a bad idea?"

- Dave

---

From: Graham <[email-masked]>
Date: Fri, 6 May 2005 14:37:54 +0100

On 6 May 2005, at 2:10 pm, Dave Johnson wrote:

>
> Yes, I think both of my arguments fail to hold and I no longer have  
> a real objection to duplicates. Allowing duplicates gives feed  
> produces to model events or other objects (versioned documents in a  
> wiki) as they wish. Like you, I wonder "Does anyone remember why  
> having the same id in a feed is a bad idea?"

Beacuse instead of a fixed model where a feed is a stream of entries  
each with their own id, it is now a stream of entries each of which  
does not have its own id, but shares it with similar entries. This is  
bullshit.

Graham

---

From: Brett Lindsley <[email-masked]>
Date: Fri, 06 May 2005 09:02:14 -0500

Unique IDs allow clients to determine the state of the feed.  If entry 
ids are
not unique, then we still need some other way to determine the unique
state of the feed. If we allow duplicate IDs but *require* something else
to be different (e.g. update time), then we can still determine the unique
state of a feed and repeated IDs are OK. We would need to properly
document which elements make an entry unique in the event of a duplicated
ID. Brett.

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 6 May 2005 10:31:17 -0400

Graham wrote:
>>"Does anyone remember why having the same id in a feed is a bad idea?"
> Beacuse instead of a fixed model where a feed is a stream of
> entries each with their own id, it is now a stream of entries each
> of which does not have its own id, but shares it with similar
> entries. This is bullshit.
	I completely disagree on this.
	I think the problem here is people focusing too much on
characteristics of the feed when the real issue here is Entries. Like I've
said in the past, "It's about the Entries, Stupid!" (don't take offense...)
	As long as we allow entries to be updated, it is inevitable that the
stream of entries that is created over time will contain instances of
entries that share common atom:id values. 
	The only question here is whether or not we're willing to allow a
feed document to *accurately* represent the stream of entries -- as they
were created -- or whether we insist that the feed document "censor" the
history of the stream by removing old instances of updated entries before
allowing updates to be inserted.
	The reality is that no matter which decision we make in this case,
any useful aggregator must have code to deal with multiple instances of an
entries that share the same atom:id. This is the case since even if we don't
permit duplicate IDs in a single instance of a feed document, we would still
permit duplicate ID's *over time." Because duplicate ids appear, over time,
whenever you update an entry, the aggregator has to have all the logic
needed to handle them in the *stream* of entries that it reads -- over time.
	This issue only becomes interesting if we try to provide special
rules for the handling of data within a single instance of a feed document.
The reality is, however, that any aggregator that actually pays attention to
these special case rules is going to either get more complex (since it can't
simply treat everything as a stream of entries) or it will get confused
(since folk will intentionally or unintentionally create duplicate ids).
	This ban on duplicate ids provides no benefit for aggregators, it
makes feed producers more complex, it tempts aggregator or client writers to
do dangerous things, it forces deletion of data that is useful to some
people for some applications, it puts too much emphasis on "feeds" when we
should be working on "entries", etc... It is a really bad thing to do.

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Sat, 07 May 2005 00:45:08 +1000

> does not have its own id, but shares it with similar entries. This is

See the spec:

    [...] Put another way, an atom:id element pertains to all
    instantiations of a particular Atom entry or feed; revisions
    retain the same content in their atom:id elements. [...]

This clearly implies that a feed is a stream of *instantiations* of an
entry.

Put another way, the map is not the territory, the <entry> is not the
'entry'.

e.

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 06 May 2005 15:58:31 +0100

Graham wrote:
>> they wish. Like you, I wonder "Does anyone remember why  having the 
>> same id in a feed is a bad idea?"
> 
> 

No, it's not, not yet. You can't reasonably call bullshit on this either 
way until we know what's being identified. When I boil it down, this is 
what I get:

"the technical problem we have is that we can't distinguish between a 
buggy feed with the same ids and an aggregate feed with the same ids 
under the current spec"

I have no good answer to that until I know what what an id stands for. 
The answer "an entry" isn't sufficient.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 6 May 2005 11:12:42 -0400

Eric Scheid wrote:
> a feed is a stream of *instantiations* of an entry.
> Put another way, the map is not the territory, the <entry> is not
> the 'entry'.
	Right. We have abstract feeds and entries and we have concrete feeds
and entries. The abstract feed is the actual stream of entries and updates
to entries as they are created over time. Feed documents are "concrete"
snapshots of this stream or abstract feed of entries. An abstract entry is
made "concrete" in entry documents or entry elements. An abstract entry may
change over time and may have one or more concrete instantiations.
	Some applications are only interested in being exposed to those
concrete entries that reflect the "current" or "most recent" state of the
abstract entries -- these apps would prefer to see no duplicate ids in
concrete feed documents even though these duplicates *will* occur in the
abstract feed. Other applications will require visibility to the entire
stream of changes to abstract entries -- these applications will wish to see
concrete feeds that may contain multiple, differing concrete instantiations
of abstract entries. i.e. they will want the concrete feed to be an accurate
representation of the abstract feed. Two needs, to views...

		bob wyman

---

From: "Roger B." <[email-masked]>
Date: Sat, 7 May 2005 01:32:04 -0500

> The answer "an entry" isn't sufficient.

Bill: Semi-random thoughts...

* An atom:id is a globally unique name for a specific database query.

* There is no "stream of instances over time". There's just old data
that's out of sync with that query.

* If duplicate ids are allowed, the world won't come to an end. I'm
almost sure. I think.

--
Roger Benningfield

---

From: Martin Duerst <[email-masked]>
Date: Sun, 08 May 2005 15:20:52 +0900

>representation of the abstract feed. Two needs, to views...

You say 'some applications' and 'other applications', as if they were on
the same footing. In my view, the 'some applicaitons' (only interested
in latest version) should be the usual case, and the 'other applications'
(interested in more than one version) should be the exception.

Mapping that back to the origin, applications generating feeds that in
one way or another rely on the user getting more than one, or more than
the latest, versions of their entries have made a design error, they
have taken the wrong thing for the 'entry'. If they think that they
have two different kinds of audiences, interested in two different
things, they should publish two feeds. Some people claim that we
need a definition for 'entry' to finish this discussion, but once
we confirm that a feed can only contain one version of an entry with
the same ID, the definition of entry is as clear as we need it to be.

This is just the same as for Web pages. If somebody puts up a Web page
for the current weather, there is nothing in HTTP that will help me
get the past versions of this page. If the publisher thinks that
people may be interested in past weather info, they will make up
separate pages. If we think that it would be valuable to be able
to correlate the entries in both feeds, we should define an
extension for that, not mess around with the basic model.
An extension would be rather easy, we only need two rel values
for links in entries. One rel value could be called "permaentry",
the other could be called "updatingentry". Maybe a third called
"updatingfeed", if there is an updating feed for a single changing
entry. I'm sure there are better names.

The main use I see for documents with multiple entries with the same
ID is archives. Everything else can be handled by the creater doing
the right thing, or by an immediary offering a new feed with versions
of the entry (no guarantee to have all of them, in that case). Even
archives could be handled that way if really needed, but it's difficult
to immagine that everybody will publish an archive feed. We can easily
define an <archive> top level element, and that problem is solved.

For aggregators, wanting to forward two or more entries with the
same ID for me means that they are simply not doing their job.
Aggregators should aggregate, not just function as GIGO (garbage
in, garbage out) processors.

So it should be clear that I'm -1 on PaceAllowDuplicateIDs.

Regards,    Martin.

---

From: Henry Story <[email-masked]>
Date: Sun, 8 May 2005 11:30:20 +0200

If I can summarize your point:

    You prefer applications that only allow one entry with the same  
id per feed.
Those that don't should use a different format that has not been  
defined yet.

This seems little weak an argument to me. I think we should permit  
certain types
of communication to take place. The applications and the consumers  
should decide
which are the most helpful to them at the time.

More details below...

> (interested in more than one version) should be the exception.

One does not need to rule what most types of applications will be most
common by making a ruling on the format of the spec. Pragmatics will
work for you very well:

  - It takes work to keep an archive of the past. As a result  
archives will
be less common.
  - Most people are interested in current changes, as opposed to past  
changes
Most applications will therefore work to satisfy current users needs,  
and
so again feeds with multiply entries with the same id will be rarer.

> things, they should publish two feeds.

Exactly. There is no need to have two formats, an archive format and
a feed format. Let applications just create two feeds for the different
uses that are made of them.

> Some people claim that we

Sorry to pick a nit, but that may help in giving one an understanding  
of what
a feed is, but not of what an entry is.

> get the past versions of this page.

((Note: Nothing stops browser from keeping a history of every url you
have ever seen though. I for one would find such a browser at times
extremely useful. We are what we read and see on the internet. Being
able to keep track of changes would help reduce the danger of the
Orwellian rewriting of history.))

> If the publisher thinks that people may be interested in past  
> weather info,
> they will make up separate pages.

But there is nothing in these separate pages that says that they
are two versions of the same thing.

This point is clearer with the wiki example. As wikis change one can
put the old versions of the wiki at separate urls. But there is nothing
to say in HTTP that these are two versions of the same content, one  
older
that the other.

What a collection of entry representations with the same id give us is
the notion of identity (and so change) over time and across uris.
This is a really important and useful concept.

> If we think that it would be valuable to be able

Yes. I agree. We can write an extension to name the particular states
(that are currently anonymous) and give pointers to a resource that
maintains the past state present. Those will be cool extensions.
Why disallow those extensions by ruling now that feeds can't have
multiple entries with the same id?

> define an <archive> top level element, and that problem is solved.

Yes, but what is the real advantage of defining an archive top level  
element
that will never make it into this spec, when we can have all that we  
need
by being flexible? In any case by admitting that a top level archive  
element
could exist you are admitting that there is not really any problem with
grouping multiple entry versions together.

> in, garbage out) processors.

I wonder why we need to specify what a good aggregator is and what
it is not. Let the applications and the market decide. We just need
to make certain types of communication possible.

> So it should be clear that I'm -1 on PaceAllowDuplicateIDs.

Should I be -1 on UTF-8 and internationalization because most people
I know are english, french or german and so that ISO-latin x is good
enough for me?

---

From: David Powell <[email-masked]>
Date: Thu, 12 May 2005 00:40:45 +0100

I'm in favour of allowing duplicate ids. This only seems to be a
partial solution though:

  "Their atom:updated timestamps SHOULD be different"

But what if they are not? What if I want to represent an archive of a
feed - maybe mine, maybe someone else's - but the atom:updated dates
are the same in two or more entries? I thought it was up to the
publisher to decide whether to rev atom:updated.

I was always concerned that the existence of atom:updated without
atom:modified would cause the meaning of atom:updated as an alert to
be diluted to being equivalent to atom:modified. This proposal would
encourage that. It would mean, if you don't update atom:updated, then
your entry instances are second class.

The restriction forces services that proxy, or re-aggregate feeds to
drop entries on the floor, just because the user has chosen not to
update atom:updated.

atom:updated encourages aggregators to make loud noises when they see
a change; anything that encourages atom:updated to be changed just for
the sake of it is going to be very annoying to users and make
atom:updated useless as an alert flag.

I'm in favour of duplicate ids, but unfortunately, the only way I can
see them working is if we have atom:modified. I hate to bring this up,
especially now, but it would solve some problems, and it is cheap to
implement:

Is anyone still opposed to atom:modified?

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Thu, 12 May 2005 09:26:06 +0200

Don't you have the same problem with atom:modified? What if the
publisher does not update the atom:modified entry?

I suppose that if you are making an archive of an atom entries and  
believe
that the author has made a mistake with the atom:updated field, you can
of course try to correct the mistake artificially in your own feed by
increasing the time precision.  So if the original entries both claim to
have been updated at 12:45 you could have one of them be modified at  
12:45:30
and the other at 12:45:31.

Just a thought.

     Henry Story

---

From: Graham <[email-masked]>
Date: Thu, 12 May 2005 10:43:28 +0100

> publisher does not update the atom:modified entry?

I presume any "atom:modified" element would have to be incremented  
every time any change was made, so this wouldn't be an option.

I prefer a solution where the originating point of the entry puts the  
current time in a new element when it generates the atom:entry. Then  
it's easy to work out which is the newest version, in a way  
atom:updated doesn't allow.

>> publisher to decide whether to rev atom:updated.

Agreed.

Graham

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 12 May 2005 19:43:35 +0200

> publisher to decide whether to rev atom:updated.

If you don't update atom:updated (e.g. it's not a "significant" update, 
fixing typos, etc.), one could (I would) assume you don't want to 
archive the previous entry "state".

There are very few chances that you "significantly" update an entry with 
the same second (that's the only way to get to the same atom:updated 
value if the "time-secfrac" is not provided), so you shouldn't have to 
track "versions" of an entry with the same atom:updated values.

So you can have a MUST instead of your SHOULD.

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 04:15:31 +1000

> publisher does not update the atom:modified entry?

Theoretically, the publisher doesn't get that choice. To not update
atom:modified would be an error.

There remains the precision issue though.

e.

---

From: David Powell <[email-masked]>
Date: Sun, 15 May 2005 23:17:57 +0100

> archive the previous entry "state".

Archiving was just an example, but the Publisher and the Archiver are
different entities. It is up to the Publisher to decide what they
consider to be a "significant" update, and it is up to the Archiver to
decide what they want to archive.

> the same second

I agree, but this proposal distorts the intended meaning of
atom:updated, and I think that this risks atom:updated becoming an
unreliable indicator for the newness of entries, which is a shame,
because it is a useful feature.

-- 
Dave