At 00:12 05/05/07, Bob Wyman wrote:
> 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...
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.
