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...
On 8 May 2005, at 08:20, Martin Duerst wrote:
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.
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.
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.
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 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.
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.
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.
((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 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.
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?
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.
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.
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.
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?
Regards, Martin.
