Subject: PaceArchiveDocument posted

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

I'd rather have held off while we discussed further, but as the 
deadline is approaching, here it is.

Abstract

Creates a new option for the document element, <archive>, which can 
contain multiple feeds or instances of the same feed, in order to 
archive the states of a feed or feeds and the states of the entries 
published while the feed was in each of those states. Specifies that 
multiple instances of a resource with the same atom:id is illegal in 
Feed Documents, Entry Documents, and if PaceAggregationDocument2 as 
adopted, Aggregation Documents, but is legal in Archive Documents.

Rationale

    1. Our charter speaks of creating an archive format.
    2. If we wish to be able to archive multiple revisions of an entry 
or the contents of a feed's head in a single document, we must either 
specify that the atom:id of a resource be repeatable within a document 
intended as an archive, or that we invent some other method of 
identifying multiple instances of the same entry or feed metadata. 
Multiple instances within an archive type document would be simpler.
    3.  Multiple versions of an entry or feed in a non-archive document 
is unprecedented in syndication formats. In spite of the fact that 
changing feed metadata after an entry is published breaks the 
connection between the state of the feed metadata at the time of 
publishing the entry and the entry, this is how feeds have always 
worked, so no exception to the one-feed-instance-per-document rule need 
be made for Aggregation Documents--that is a special case reserved only 
for archiving.

See http://www.intertwingly.net/wiki/pie/PaceArchiveDocument for more.

---

From: James M Snell <[email-masked]>
Date: Sat, 05 Feb 2005 22:03:14 -0800

Hmm.. I'm sorry but this just seems wierd to me.

<archive>
   <head>...</head>
   <feed>
     <entry>
       <id>id:version1</id>
     </entry>
   </feed>
   <feed>
     <entry>
       <id>id:version2</id>
     </entry>
   </feed>
   <feed>
     <entry>
       <id>id:version3</id>
     </entry>
   </feed>
</archive>

What is the point of having the feed elements in there at all?  If
entries are indeed able to stand on their own, why not just go ahead and
get rid of the containing feed element altogether?  I mean, it is the
entries that are being archived, not the feeds that just happened to
contain them at some moment in time right?

<archive>
   <head>...</head>
   <entry>
     <id>id:version1</id>
   </entry>
   <entry>
     <id>id:version2</id>
   </entry>
   <entry>
     <id>id:version3</id>
   </entry>
</archive>

I guess I just don't see the point of archiving the feed.

- James M Snell

Antone Roundy wrote:
> 
> I'd rather have held off while we discussed further, but as the deadline 
> is approaching, here it is.
> 
> Abstract
> 
>    2. If we wish to be able to archive multiple revisions of an entry or 
> the contents of a feed's head in a single document, we must either 
> changing feed metadata after an entry is published breaks the connection 
> between the state of the feed metadata at the time of publishing the 
> entry and the entry, this is how feeds have always worked, so no 
> exception to the one-feed-instance-per-document rule need be made for 
> Aggregation Documents--that is a special case reserved only for archiving.
>

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 6 Feb 2005 02:00:20 -0500

-1.
	The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to try to
rush through something this major at the last moment before a pending Last
Call.

		bob wyman

---

From: Henry Story <[email-masked]>
Date: Sun, 6 Feb 2005 09:08:04 +0100

> rush through something this major at the last moment before a pending 

I agree. Very serious -1 for me.

I think the versioning element of id works very well. I am using it
in my BlogEd model currently. I think the feed works very well as
an archiving format already. No need to change anything that works well.

Furthermore I think one should prove that harm is being done by the
id as version feature (which would be difficult to show, because I have 
implemented this, Bob has implemented it, and neither of us have
come across a problem).

Henry

---

From: Sam Ruby <[email-masked]>
Date: Sun, 06 Feb 2005 10:39:05 -0500

> implemented this, Bob has implemented it, and neither of us have

We already have a problem - Bob wanting updated to mean modified.

Pardon me for observing that the two individuals mentioned are above 
average in intelligence, and actually read specifications - an unusual 
trait.

If you produce feeds that contain multiple entries with the same id, 
there will be people who misunderstand such documents.

I do believe that there needs to be some way to say "this is not a feed, 
but an archive".

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sun, 6 Feb 2005 16:06:35 +0000

On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote:

> I do believe that there needs to be some way to say "this is not a 
> feed, but an archive".

Solution:
A new atom:archive top level element with normal head and entry 
children. Difference is multiple instances of entries are allowed with 
the same id. Each is distinguished by a new atom:version date, that has 
no semantics other than determining which instance is the newest. 
Meanwhile, atom:version and multiple instances are explicitly banned 
from atom:feed.

?

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 06 Feb 2005 16:25:50 +0000

> Meanwhile, atom:version and multiple instances are explicitly banned 

An uncomfortable thought (for me). Perhaps this a use-case for @profile. 
  If Mark is following this, he might be able to comment on that. Mark?

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Sun, 06 Feb 2005 11:35:05 -0500

> Meanwhile, atom:version and multiple instances are explicitly banned 

Works for me.

Presumably, atom:entry elements can have at most one atom:version child 
element.  But, are atom:version elements be required in atom:archives?

- Sam Ruby

---

From: [email-masked] (John Panzer)
Date: Sun, 06 Feb 2005 08:50:57 -0800

Antone Roundy wrote:

> worked, so no exception to the one-feed-instance-per-document rule 
> need be made for Aggregation Documents--that is a special case 
> reserved only for archiving.
>
I'm +0 on repeated instances for archives, if it's sufficient for some 
use case and doesn't delay the draft.

But, given that I don't know what the use case for this is, I'm 
concerned that this is going to be the start of a slew of issues.

Some people may be expecting to be able to use the "archive format" to 
store the entire state of their blog/wiki/whatever, at least as a 
snapshot.  But all the current proposals ignore the crucial issue of how 
I archive the state of my cat pictures.  Seriously -- how can I create a 
self-contained document that includes both entry and non-entry resources 
which point at each other? [1].  To be clear, I think this is not 
something we should tackle at this point, but I fear that the word 
"archive" may conjure up an image of something you could use for, say, 
backups.

Second, if the intent of tracking state is to be able to go back to a 
prior version of the feed:  This ignores the issues of intra-feed links, 
for example those of comment feed(s).  For example, let's say I get an 
archive of the history of a (comment) feed.  Each entry in this feed 
will have a URI for the parent entry.  But, the parent entry itself can 
change over time -- the URI is for an entry, not an entry instance.  For 
general URIs, this is just something to live with; but one might 
reasonably expect an archive format to be able to archive an entry plus 
its comments together, and if it claims to archive historical changes, 
to be able to get to a 'state of the site' on demand.

Finally, how does one obtain an archive document?  A new endpoint? 

-John Panzer
http://journals.aol.com/panzerjohn/abstractioneer

[1] This might be a good use for multipart/related and cid:.  But that's 
a much bigger kettle of fish.

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 6 Feb 2005 14:20:55 -0500

Sam Ruby wrote:
> If you produce feeds that contain multiple entries with the same
> id, there will be people who misunderstand such documents.
	So what? If they initially misunderstand, they will eventually learn
how to do it properly.
	In any case, I think you miswrote the quoted sentence. I believe you
are talking about "feed documents" not "feeds". The simple fact is that
according to the Atom specification as it stands and according to the common
useage in the syndication world, feeds frequently have multiple entries with
the same atom:id. By "feed" I mean, of course, the abstract thing of which a
feed document presents a subset. The issue here is not whether *feeds* can
contain multiple same-id entries, but rather whether feed documents can do
so.
	The *real* issue here is that we never had the "BAG" discussions
that I was pleading for back in the summer... A "Blog Architecture" would
have answered questions like "What is a Feed?" "What is an entry?" how does
a Feed differ from a Feed Document, etc... If nothing else, we might have
come to use a common vocabulary.
	In this particular debate, the core issue is "What is a Feed
Document?" I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have said that a Feed Document is "a
representation of the current state of a set of entries." The difference is
significant. For instance, if you accept the "sliding window" view, then
since a feed (the abstract thing) can have multiple instances of entries
with the same atom:id, then it is obvious that a Feed Document should have
the same property. On the other hand, if you accept the "current state"
definition of a Feed Document, you end up saying that while a Feed can have
multiple same-id instances, it is clear that a Feed Document cannot since
there is only one "current state" of a resource at any one time.
	In either case, the definition of "Feed Document" implies the
answer, without debate, to the question: "Can a Feed Document contain
multiple entries with the same atom:id?" Had we dealt with architectural
issues, this debate would not and could not be happening. The same can be
said about a number of other issues before us now. Sayre and others have,
for instance, complained regularly about the lack of agreed definitions
concerning "What is an Entry...", etc. Our terminology is sloppy. We haven't
done our jobs well.
	I contend that we should adopt the sliding window definition of a
feed simply because it is the most useful and easiest to implement. It makes
"archiving" simple, it allows those who are anal about getting "every
change" to get them, and it makes it possible for us to implement bandwidth
saving measures such as RFC3229+feed. None of these things are possible,
without the creation of a special "archive" type, if one adopts the "current
state" view. Given that the "sliding window" view addresses a wider variety
of requirements, I think we should adopt it as the primary view.
	With sliding windows, the only thing you need to do to update a feed
document is insert at its head the new or changed entry. (You could also
just append to the tail of the file. Order should not be significant in an
Atom file...) On the other hand, the "current state" view requires that you
scan the current Feed Document and remove any pre-existing entry that has
the same atom:id as the one you are inserting. 
	The difference in Feed Document updating may not seem to be big,
however, it becomes significant when we consider things like the
RFC3229+feed that is currently responsible for *massive* bandwidth savings
for those that use it. RFC3229+feed, as written, assumes a "sliding window"
view of Feed Documents and can be simply implemented by simply associating
ETags with the various points in a document at which entries are inserted.
Constructing the "diff" of a feed document is then simply a question of
indexing back into the Feed Document to the ETag in question and copying all
the data inserted after the ETag. However, if the "current state" view of a
feed is required, then it becomes necessary on entry insertion or on
retrieval to process each entry in the sliding window to filter out
duplicate atom:ids. The result is more processing for the server and a great
deal more complexity in the implementation. My fear is that the increased
complexity (which probably requires a database approach -- not just a
sequential file with "ETag cursors" pointing in to it) is sufficient that
people won't implement RFC3229+feed. The result would be wasted bandwidth,
etc...
	Of course, adopting "current state" instead of "sliding window" also
means that we have to invent the atom:archive type so that we can produce
the sliding window view which is implied by the archive requirement. Thus,
we're making things more complex by offering both "current state" and
"sliding window" views.
	It has been argued by a number of people that we can't adopt
"sliding window" since the ability to have multiple instances of a since
entry in a Feed document is "unprecedented" in the history of blogging and
syndication!!! This is, of course, a completely false statement. The reality
is that in RSS and Atom feed documents in use today, one often sees the same
id or guid being used for multiple entries. In fact, the most popular id or
quid is "null" or nothing... The result has, of course, been that virtually
no existing aggregators actually do anything useful with ids or Guids
(unless they are in RSS V2.0 and flagged as permalinks.) This lack of use
for non-permalink guids resulted from the under-specification in previous
versions of syndication formats as well as the fact that GUIDs were
generally optional. But, an essential element of the Atom format is that
atom:id is *required* and thus can be used for useful purposes. It is that
expectation that an atom:id or guid is *useful* that is unprecedented in
Atom... In any case, why in the world would the fact that something is
"unprecedented" be a bar to our adopting it? Are we forbidden to innovate?
Must we propagate all the errors of the past?
	Anyway, I am convinced that the "current state" view is less useful
then the "sliding window" view. The current proposals to define an "archive"
type to patch "sliding window" into Atom are excellent indications that I'm
right... I know others disagree... I also realize that not many people will
actually read this whole message. Ah well...

		bob wyman

---

From: Henry Story <[email-masked]>
Date: Sun, 6 Feb 2005 21:22:21 +0100

I have read your message in full, and I am totally convinced by your
argument. I think the sliding window view is clear, simple and powerful.
(I also think it can easily be modeled in RDF.)

Many +1's from me.

Henry Story

On 6 Feb 2005, at 20:20, Bob Wyman wrote:
> The current proposals to define an "archive"

---

From: [email-masked] (John Panzer)
Date: Sun, 06 Feb 2005 12:56:49 -0800

Bob Wyman wrote:

>I have long contended that a Feed Document is a "sliding window"
>representation of the current state of a set of entries." 
>
Agreed that these are different and that defining which is 
acceptable/required is needed.  For example, if a feed _must be_ a 
"sliding window", that would imply that a database-backed bloggin 
system_must_ keep track of the past state of Entries in order to be able 
to generate a feed on demand.

If a feed _must be_ a "representation of the current state of a set of 
entries", then intermediate aggregators _must_ do duplicate detection 
and decide which version to pass on.

I can see pros and cons either way.  But I think that failing to decide 
would be worse than picking either: It would result in subtle confusion 
and interoperability headaches.

So I'm +1 on picking one and documenting it.

John Panzer

---

From: Sam Ruby <[email-masked]>
Date: Sun, 06 Feb 2005 15:58:36 -0500

> 	So what? If they initially misunderstand, they will eventually learn

It is quite possible that "they" outnumber "you".  I have seen the spec 
definition of elements in feed formats become /overtaken by events/, and 
eventually become defined by the common usage as opposed to the spec usage.

[snip]

> significant.

[snip]

> actually read this whole message. Ah well...

Who is "right" is not important to me.

If there are two different approaches, and those differences are 
"significant", I want those differences to be explicit in the document.

My weblog software does not maintain a historical perspective.  To the 
best of my knowledge, neither does Blogger, MovableType, TypePad, 
Blosxom, WordPress, etc.  Feeds from such tools will inevitably, 
therefore, represent a "current state" view.

Nor, do I expect that these tool manufactures have any interest in 
learning "how to do it properly".

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Mon, 07 Feb 2005 08:16:56 +1100

> there is only one "current state" of a resource at any one time.

just another data-point: I've long worked from the definition that a Feed
Document is "a representation of a set of entries". None of this "current
state" malarky, and no "sliding window" requirement. Both Archive Documents
and Sliding Window Feed Documents can exist in this model.

e.

---

From: Robert Sayre <[email-masked]>
Date: Sun, 06 Feb 2005 16:50:09 -0500

> actually read this whole message. Ah well...

It is irritating but necessary to have this discussion right now. Thank 
you for starting it. At the end of it, the first paragraph of The Atom 
Syndication Format should contain less handwaving, at the cost of some 
astronautic emails like this one.

I contend the "sliding window" and "current state" positions aren't 
really opposed at all. Let's start with your own site:

http://bobwyman.pubsub.com/
http://bobwyman.pubsub.com/main/index.rdf

The naming convention should be a tipoff. Users expect a machine 
readable version of your index page. It would be confusing for the index 
page of your site to contain multiple copies of the same entry, and I 
contend it is similarly so for the feed document.

So, how to record state transitions PubSub has witnessed between hits 
from a subscribing client? I would simulate a sequence of HTTP GET requests:

--------------------------------------
...
<feed>...</feed>
<feed>...</feed>
<feed>...</feed>
<feed>...</feed>
...

I think we should make feed/id mandatory for two reasons:

1.) If you can't generate an id for your feed, you're never going to 
succeed with the entries, and it will make a useful base string, like 
your address does for email.

2.) Multiple feed elements could have the same atom:id, simulating 
multiple GETs.
--------------------------------------

Do we have to spec this now? No.

> (unless they are in RSS V2.0 and flagged as permalinks.)

This is, of course, a completely false statement. Here is NetNewsWire's 
sync data:

		<key>tag:www.franklinmint.fm,2004://1.187</key>
		<dict>
			<key>created</key>
			<date>2004-09-23T12:26:11Z</date>
			<key>flagged</key>
			<false/>
			<key>followed</key>
			<true/>
			<key>read</key>
			<true/>
		</dict>

Also, Thunderbird uses them to compose its "message-id".  I could go on.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sun, 6 Feb 2005 20:47:38 +0000

> feeds frequently have multiple entries with the same atom:id

Can you name one example that wasn't written by an arsehole trying to 
trick aggregators into behaving in a way they weren't designed to?

> representation of the current state of a set of entries."

False dichotomy. It's a sliding window of current states. You've 
started with your conclusion and worked backwards. The whole argument 
is invalid, no matter who many words you asterisk.

> I also realize that not many people will actually read this whole 
> message. Ah well...

This is one of those things were anyone that disagrees gets told they 
haven't read it, just don't get "it".

Graham

---

From: [email-masked] (John Panzer)
Date: Sun, 06 Feb 2005 13:58:20 -0800

>and Sliding Window Feed Documents can exist in this model.
Since an entry is identified uniquely by its atom:id (though it can have 
different states at different times);
And, since it's not possible to add more than one of any unique thing to 
a (mathematical) set;
And, since Sliding Window may require adding two <entry> elements with 
the same atom:id to the same feed:

I'm not sure how Sliding Window can exist in this model.  Maybe you 
meant "a set of entry instances"?

-John

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 06 Feb 2005 22:16:43 +0000

> there is only one "current state" of a resource at any one time.

If I don't take a technical interpretation of the word 'set', there's no 
  useful distinction (which is to say I don't see a need to specify
one over the other).

> issues, this debate would not and could not be happening. 

With no malice: you're assuming we'd be finished dealing with the
architectural issues by now.

> we're making things more complex by offering both "current state" and

The archive element is being invented so people can treat the entire 
lump of XML as an archive. It's a control code, not an artefact of a model.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 06 Feb 2005 22:18:07 +0000

> meant "a set of entry instances"?

This is exactly what I meant in my last mail. The word 'set' is being 
taken too seriously. I don't think that's warranted.

cheers
Bill

---

From: Dan Brickley <[email-masked]>
Date: Sun, 6 Feb 2005 17:24:53 -0500

* John Panzer <[email-masked]> [2005-02-06 13:58-0800]

> different states at different times);

As I understand the Web, the "REST" concepts that underpin HTTP
are quite happy with their being multiple representations of 
the selfsame resource *at the time*. The state captured in 
the documents that fly around the Web can be one of several that 
are associated with a common abstract entity. I'm not sure how 
this fits with the "sliding window" vs "current state" views 
of Atom. I guess I've always seen feeds as just being documents
that are about some other documents, and whose state and 
selection of document coverage / detail is naturally going to 
vary depending on the sort of site we're dealing with.

Dan

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 6 Feb 2005 15:09:57 -0800

On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote:
> the selfsame resource *at the time*.

Also at multiple times.

Yes, it's all about time, but also about resources.  The entry is
a resource, and that resource may have multiple representations at
a single time (atom, rss1, rss2) and also over different times.
A resource has a single state at one point in time, but may have
different states over time (in some case they must have different
states over time because that is the essence of what makes them
a resource, just as a clock is expected to have different state).
URIs identify resources, not necessarily singular states.

Feeds are sliding window resources, but their representations
do not slide -- they are fixed at a given point in time.  If it is
reasonable to say that, at any single point in time, only one
representation of a given entry can appear in the feed's
representation, then the only valid representation of a feed
is one that does not contain any duplicate entry id's.

An atom:feed document is a representation of a single feed
resource at a single point in time.

Aggregators do not consume feed resources -- they consume an
iterative set of overlapping feed representations.  Aggregators
are therefore required by Atom to only include the "latest"
version of an entry within their own resource representations.

I believe that these requirements reflect the desires of most
of the participants in this working group, so it seems to me
that the question has been answered.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Eric Scheid <[email-masked]>
Date: Mon, 07 Feb 2005 11:18:03 +1100

On 7/2/05 8:58 AM, "John Panzer" <[email-masked]> wrote:

> different states at different times); And, since it's not possible to add more
> than one of any unique thing to a (mathematical) set; And, since Sliding
> Window may require adding two <entry> elements with the same atom:id to the
> same feed:
> 
> I'm not sure how Sliding Window can exist in this model.  Maybe you meant "a
> set of entry instances"?
> 

I didn't specifically define "set" to be the more limited mathematical
definition. Think dining room set -- a collection of otherwise identical
items (chairs).

e.

---

From: [email-masked] (John Panzer)
Date: Sun, 06 Feb 2005 17:09:30 -0800

>definition. Think dining room set -- a collection of otherwise identical
Okay.  I suggest we use the word "collection" for this concept to avoid 
confusion.  You're saing that a Feed Document is "a representation of a 
collection of entries"; I don't think anyone would argue with this.

-John

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 6 Feb 2005 21:42:16 -0500

Roy T. Fielding wrote:
> iterative set of overlapping feed representations.
	This is only true of pull based aggregators that poll for feeds.
None of the aggregators that I use are polling based. I use the PubSub
Sidebars and the Gush aggregator built by 2entwine.com. These aggregators
consume streams of entries that are pushed to them using the "Atom over
HTTP" protocol. See:
http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-02.txt
	As I've said on numerous occasions: "It's about the Entries,
Stupid!" The whole "feed" business is simply an artifact of the
polling-based model of syndication. The Entry should be the core element of
Atom, not the Feed. The Feed, as a collection, is there to serve the Entries
-- not the reverse. Feeds are just a way of bundling up Entries while the
server is waiting for readers to poll for results. But, what readers are
fundamentally interested in is the entries in the feed, not the feed itself.

	The polling oriented, feed-based model of syndication results in
significant waste of network bandwidth and processing resources as well as
introducing significant latencies between when items are published and when
they are accessed by readers. (i.e. average latency is 1/2 the polling
frequency.) While the use of push-based aggregators may not be widespread,
it does not make sense, I think, to bind Atom to the inefficient,
high-latency polling model when we know that there is a workable alternative
approach -- which is far superior in at least some important applications of
syndication.
	A push-fed aggregator never sees feeds -- except on startup when it
might read a feed in order to catch-up on entries that were published while
it was off-line (if the push server doesn't do guaranteed, queued delivery).
From the point of view of a push-fed aggregator, a feed is simply a log of
the stream of entries that were pushed to it or would have been pushed to it
if it had been online. i.e. it is a static archive of the dynamic stream. 
	To touch on another issue recently discussed: A push-fed aggregator,
because it sees streams of entries, not feeds, simply cannot exploit or even
discover any "feed order" information other than pure chronological order.
To require that any significance be given to "order in feed" is essentially
the same as prohibiting the use of Atom in poll-fed aggregators. In a
push-fed aggregator that sees a steam of entries, it is essential that any
inter-Entry relationships be specified within the entries themselves. No
other information is available...
	The Atom spec will live or should live for a long time. It would
not, I think, be good to tie it too tightly to the inefficient, high-latency
polling model -- even though that model is the most commonly used today.

		bob wyman

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Feb 2005 19:03:05 -0800

This is why I prefer "snapshot" to "feed"; the latter doesn't convey 
what an Atom Feed Document really is, and leads to just this kind of 
confusion.

Another direction to go in would be to add metadata (probably in the 
head) that says what kind of feed it is; e.g., "an archive," "a 
snapshot of the last three days," "a snapshot since last Monday," "a 
snapshot of the last 10 entries." This might add some complexity, but a 
stub that just allowed you to differentiate between archive and 
snapshot might be useful, and could be extended upon in the future, 
while remaining pretty simple now.

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

---

From: Henry Story <[email-masked]>
Date: Mon, 7 Feb 2005 11:38:37 +0100

> URIs identify resources, not necessarily singular states.

It is about resources, but the question is what the id resource  
identifies.
There are two things the id resource could identify:
   a- the uri of the entry (rdf:about)
   b- a uri related to the entry by the id relation (rdf:resource)

I find interpretation b to be the most powerful one, because it
allows us to narrow the disagreement between both factions down
to the properties of the id relation.

Here is how I model in rdf arrow notation the atom example [1]:

_entry
   |--title-> "Atom Powered Robots Run Amok"
   |--link--> <http://example.org/2003/12/13/atom03>
   |--id----> <vemmi://example.org/2003/32397>
   |-update-> "2003-12-13T18:30:02Z"^^xsd:dateTime

The differences this group has as to the interpretation of the
id relation can be explained as follows:
   -those that like Bob Wyman and me-currently, believe that id is
    just a functional relation. Call this the [Functional Id] theory.
   -others like Roy Fielding and me-when-I-first-thought-of-the-issue,
    think of id as an equivalence relation  (which I think just means
    that the relation is functional, symmetric and transitive). Call
    this the [Equivalence Id] theory.

Under the [Equivalence ID] theory, the above graph has the following
graph as consequence.

<vemmi://example.org/2003/32397>
     |--title-> "Atom Powered Robots Run Amok"
     |--link--> <http://example.org/2003/12/13/atom03>
     |-update-> "2003-12-13T18:30:02Z"^^xsd:dateTime

The above conclusion cannot be drawn from the [Functional ID]
theory.

Note that both theories:
   - are expressed in terms of resources
   - could easily be compatible: it would just require
     distinguishing the [Equivalence ID] relation and the
     [Functional ID] relation by naming them differently.

     Let us do so now:

     [Functional ID] -> funcId
     [Equivalence ID] -> equivId

> do not slide -- they are fixed at a given point in time.

Yes, I agree. But the time component is only as important as you
say if you emphasize http URIs for your id. But that will come out
more clearly below.

> If it is

This is true only if you have the [Equivalence ID] interpretation
of the id relation. (Ie you think of id as equivId.)

To give a more concrete example let us use the well understood
http URIs for our ids, and let us disambiguate the two id types.

_entry
   |--title---> "Atom Powered Robots Run Amok"
   |--link--> <http://bblfish.net/2005/02/07/entry03/v2/entry.html>
   |--funcId--> <http://bblfish.net/2005/02/07/entry03/>
   |--equivId-> <http://bblfish.net/2005/02/07/entry03/v2/>
   |-update---> "2003-12-13T18:30:02Z"^^xsd:dateTime

The file system layout would be something like the following
(taking root at 2005/02/07 to save space)

entry03    <-- a directory resource pointed to by the funcId uri
entry03/v1 <-- a directory resource for the previous entry version
entry03/v1/entry/xml  <-- the first entry version of the xml
entry03/v1/entry.html <-- the second entry version in html form
entry03/v2 <-- a directory resource pointed to by the equivId uri
entry03/v2/entry.xml  <-- the second entry version in xml format
entry03/v2/entry.html <-- the first entry version in html format

With the above file system layout it would therefore be completely
feasible to have a feed that would correctly state at a precise time
the following:

<feed>
   <entry>
     <title>Atom-Powered Robots Run Amok</title>
     <link href="http://bblfish.net/2005/02/07/entry03/v1/entry.html"/>
     <funcId>http://bblfish.net/2005/02/07/entry03/</id>
     <equivId>http://bblfish.net/2005/02/07/entry03/v1/</id>
     <updated>2003-12-13T18:30:02Z</updated>
   </entry>
   <entry>
     <title>Atom-Powered Robots Run Amok</title>
     <link href="http://bblfish.net/2005/02/07/entry03/v2/entry.html"/>
     <funcId>http://bblfish.net/2005/02/07/entry03/</id>
     <equivId>http://bblfish.net/2005/02/07/entry03/v2/</id>
     <updated>2003-12-13T18:30:02Z</updated>
   </entry>
</feed>

There are indeed two versions of the entry at one point in time
with the same funcIds specified above, but as you also rightly
point out two *different* equivIds.

> resource at a single point in time.

ok.

> version of an entry within their own resource representations.

Only if you reduce the toolset available by requiring no one use
a funcId relation. Otherwise it is quite possible to have multiple
versions of an entry in the same feed as I clearly showed above.

> that the question has been answered.

Now is the time to question this statement.

I would like to start by an obvious objections someone is bound
to make to the example file system layout I described above, namely
that it is much too complicated for most end users [2],
and that most blog layouts will only have a simple, non versioned,
layout. Something more like this:

2005/02/07/entry03    <-- a directory resource for the entry
2005/02/07/entry03/entry.xml  <-- the xml version of the entry
2005/02/07/entry03/entry.html <-- the html version of the entry
2005/02/07/entry04/  <-- a directory resource for another entry
2005/02/07/entry04/entry.xml
2005/02/07/entry04/entry.html

If the id were to point to the

<http://bblfish.net/2005/02/07/entry03/>

resource, as one would be tempted to do, then this would clearly
imply a [Equivalence ID] interpretation of id, and so of course
having two differing entries with the same id in a feed document
would be saying something contradictory and false.

This is an obvious intuition, that I myself followed for a long time.

But of course this does not take into account this groups very long
and convoluted discussions concerning the Identity Constructs, and
the discussions about what an id really should be: should it just be
a String? A String that can be seen to be a URI, but should not
be thought to be one? ... Many people have vocally tried to
limit the URIs allowed for an id to the set of URIs that are *not*
URLs. In fact the default example given in the spec does not use
a URL but some 'vemmi' URI.

Non URL URIs such as 'vemmi' URIs are needed to create a non
temporal identity of an entry that allows even simple file system
layouts such as the one just shown to be given an id that makes
sense in the [Functional ID] interpretation.

Here is how the feed can be composed of such entries without
this raising any special problem.
<feed>...
   <entry>
     <title>Atom-Powered Robots Really Run Amok</title>
     <link href="http://example.org/2003/12/13/atom03"/>
     <funcId>vemmi://example.org/2003/32397</id>
     <updated>2005-02-07T09:30:02Z</updated>
   </entry>
   <entry>
     <title>Atom-Powered Robots Run Amok</title>
     <link href="http://example.org/2003/12/13/atom03"/>
     <funcId>vemmi://example.org/2003/32397</id>
     <updated>2003-12-13T18:30:02Z</updated>
   </entry>
</feed>

Since entries here described are just versions of the
   <vemmi://example.org/2003/32397>
atemporal entry.

So without trying to work out or guess what the changing desires
of this working group are (I myself moved from one side to
the other on this issue), I think we should rather try to decide
on by weighing as Bob Wyman did, the advantages of each.

And if this still does not allow one to choose one should perhaps
just allow both.

Henry Story

Ps. If you do read this please send me a postcard, or short e-mail
    :-)

> Chief Scientist, Day Software              <http://www.day.com/>

[1] _entry is a blank node as indicated by the leading '_'
     The graph is a simplified version of a full model for purposed
     of focusing on the current problem
     The atom example is the one available here:
<http://atompub.org/2005/01/27/draft-ietf-atompub-format 
-05.html#rfc.section.1.2>
or here <http://tinyurl.com/58z6g>

[2] though I wonder really how much weight arguments like this should
have on IETF (Internet *Engineering* Task Force) groups, where we
are already in the process of writing a huge spec, that requires
understanding if HTTP, XML etc, none of which are that simple...

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Feb 2005 04:13:10 -0800

On Feb 6, 2005, at 6:42 PM, Bob Wyman wrote:
> HTTP" protocol.

No, they consume feed representations of length=1, which contains
an entry representation.  They are neither streams nor entries, and
if we stop confusing the messages received with the rather abstract
notion of what the author considers to be their entry, then it is
much easier to understand what the id tells the recipient.

This is not specific to the transfer protocol.  It is an aspect
of message passing architectures.  Most network-based systems
build tremendously complex synchronization and update mechanisms
in an attempt to make message passing match what an ideal
world would consider reality.  Unfortunately for them, the theory
of relativity is just as applicable to software as it is to us.

HTTP (or at least the use of HTTP based on REST) changes the
perspective by acknowledging that messages are not the same
as what is identified.  It seems a little odd, at first,
but it makes a huge difference because clients stop assuming
that they have a complete understanding, servers supply more
explicit information about what they do send, and the overall
system becomes less brittle during failures. However, HTTP
only tries to match what is already true of message passing --
it does not make the rules.

Regardless of the protocol used to receive an atom feed, the
only things that will actually be received are representations.
Computers can't transfer a temporal mapping that has yet to
be defined.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Feb 2005 04:33:33 -0800

> say if you emphasize http URIs for your id. But that will come out

No, Henry, the time component comes from a person's ability to
change an entry over time.  The URI is only relevant in the sense
that it has to allow a variable mapping over time, which is true
of all URIs that are in actual use today [not including some of
the fixed-content or fixed-time URI schemes that have been
proposed but not actually deployed].

> of the id relation. (Ie you think of id as equivId.)

Yes, and to make myself perfectly clear, that means functional ID,
as you call it, would conflict with the design of Atom and any
reasonable design of a system wherein the things being identified
are allowed to be updated over time.  So, please, stop trying to
make a real system fit an artificial model of graph theory that
isn't even capable of describing the Web.  Fix your model instead.

....Roy

---

From: Dan Brickley <[email-masked]>
Date: Mon, 7 Feb 2005 07:34:53 -0500

* Roy T. Fielding <[email-masked]> [2005-02-07 04:13-0800]
> much easier to understand what the id tells the recipient.
 
+1;  we're exchanging representations (or maybe 'descriptions') not the 
things themselves. This becomes a lot clearer when we think about 
feed markup that describes people, places, products etc. inside the 
entry/item descriptions.

> Computers can't transfer a temporal mapping that has yet to

This thread is getting to the core of the different styles 
of thinking about RSS and Atom feeds. It is pretty widespread 
for people to think about RSS/Atom feeds in non-RESTy terms, 
ie. that the chunks of markup are 'the things themselves,
being transported around the net'. From the RDF side of things,
it is more natural to take the other view and see feeds as 
documents that describe things (such as themselves, items/entries,
and the -- often realworld -- things those entries are about...).

I am glad to see this discussion happening

Dan

---

From: Henry Story <[email-masked]>
Date: Mon, 7 Feb 2005 14:15:25 +0100

On 7 Feb 2005, at 13:33, Roy T. Fielding wrote:
> are allowed to be updated over time.

I wonder if you read the rest of my message...

I gave an example that did not conflict with a reasonable design.
Here is a reasonable design of the files in a web site for an entry 
with versioning:

entry03/v1/entry.xml  <-- the first entry version of the xml

Here is a reasonable feed corresponding to the above file system
layout of resources:

<feed>
   <entry>
     <title>Atom-Powered Robots Run Amok!</title>

((It seems to me that when blogging it is very good practice
to keep the changes of one's entries available as above, since
one's changing one's mind on an issue affects the pages and comments
of other people pointing to your entry.))

Anyway, as you see I am agreeing with you that equivId will be
different for each entry in a feed, though funcId is the same.
There we have a feed that contains both notions.

> So, please, stop trying to

Do you have a good paper that proves your incredibly strong statement
above? I would be happy to understand this position, as it would save
me a lot of time. But I can't just take your word for it, as there
are numerous people who don't seem to think the way you do, and in
just as senior or more senior positions than your are. But perhaps
I have missed some important development recently. (I am not being 
ironic here though it may sound like it. I really would like to
understand more fully your position.)

Henry Story

---

From: Henry Story <[email-masked]>
Date: Mon, 7 Feb 2005 14:39:47 +0100

> entry03/v2/entry.html <-- the first entry version in html format

Clearly there were a few typos in the above:

entry03    <-- a directory resource pointed to by the funcId uri
entry03/v1 <-- a directory resource for the previous entry version
entry03/v1/entry.xml  <-- the first entry version in atom xml
entry03/v1/entry.html <-- the first entry version in html format
entry03/v2 <-- a directory resource pointed to by the equivId uri
entry03/v2/entry.xml  <-- the second entry version in xml format
entry03/v2/entry.html <-- the second entry version in html format

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 09:07:41 -0700

On Sunday, February 6, 2005, at 09:35  AM, Sam Ruby wrote:
>> children. Difference is multiple instances of entries are allowed 
>> with the same id. Each is distinguished by a new atom:version date, 
>> that has no semantics other than determining which instance is the 
>> newest. Meanwhile, atom:version and multiple instances are explicitly 
>> banned from atom:feed.
>> ?
>
> Works for me.
>
> Presumably, atom:entry elements can have at most one atom:version 
> child element.  But, are atom:version elements be required in 
> atom:archives?
>
Okay, so we are punting on defining a way to archive the changing state 
of feed/head.

Making something like the above semi-concrete:

<archive>
	<head>
		...
	</head>
	<entry>
		<id revision="3">foo:bar/a</id>
		...
	</entry>
	<entry>
		<id revision="2">foo:bar/a</id>
		...
	</entry>
	<entry>
		<id revision="1">foo:bar/a</id>
		...
	</entry>
	...
</archive>

...where @revision is a number whose only requirement is that the 
number for a later revision be greater than the number for an earlier 
revision, but skipping numbers is allowed.

@revision could go in <entry> instead of <id>, or could be <revision>.

We're at the deadline for paces.  Someone who wants something like this 
should write one today.

---

From: Walter Underwood <[email-masked]>
Date: Mon, 07 Feb 2005 08:57:37 -0800

I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.

So, it is not possible for the current doc to fulfill the charter, and
this document is not ready for last call.

wunder

--
Walter Underwood
Principal Architect, Verity

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 12:06:46 -0500

> model, we can't spec syntax.

We have feed documents. A series of feed documents makes an archive. I 
don't see why we need atom:archive after all.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 10:16:17 -0700

On Sunday, February 6, 2005, at 07:42  PM, Bob Wyman wrote:
> The whole "feed" business is simply an artifact of the
> polling-based model of syndication.
Interesting to hear the architecture for the model that most people use 
today be referred to as an "artifact".  But yeah, to someone who 
doesn't used polling aggregators, it would seem so.

> significant waste of network bandwidth
The "sliding window" view into the historical states of entries (vs. a 
sliding window into the current states of entries) would also waste 
some bandwidth transmitting obsolete entry states, and could result in 
missed entries if someone writing an entry does a lot of tweaking and 
publishes each tweak (thus filling their feed document with versions of 
a single entry), which, though sloppy methodology, is probably not 
entirely uncommon--just my guess.  Polling combined with diffs of the 
current state of entries would use similar bandwidth to push...
> and processing resources
...and wouldn't require the server to keep track of all of its 
subscribers, and would result in bandwidth usage being spread over time 
better than push, assuming push servers push new entries out to 
everyone as quickly as possible after they're published.  Both methods 
have their advantages, many more of which could be listed on either 
side, I'm sure.

> While the use of push-based aggregators may not be widespread,
Agreed.  But I've lost track of what aspect of Atom's architecture you 
are saying is bound to polling at the expense of push.  Are we still 
talking about sliding window vs. current state?  If so, what difference 
does that make to a push-based aggregator?

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 09:13:20 -0800

+1.  We need to at least discuss the model a bit more before agreeing to
a syntax.  As with all things, there are many different ways we can do
this -- a new top level elements, the @profile attribute Mark and I have
been pitching, etc -- but unless we identify the general requirements
and a general model that we're shooting for, whatever we scrap together
here at the last minute is not going to be completely adequate.

- James M Snell

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 10:29:18 -0700

> don't see why we need atom:archive after all.
If Atom Documents are not allowed to contain multiple instances of a 
particular resource, then archiving the states of an entry would 
require the feed to be split into more, smaller feed documents any time 
an entry is edited without many other entries being published in 
between edits.  For example, if you published an entry, decided to 
revise a paragraph and published again, found a misspelling and 
published again, and then fixed and published another misspelling, 
you'd need four documents, two of which would only contain one entry.  
Doable, yes.  But a little ugly.

If, on the other hand, a feed document is a sliding window into the 
historical states on entries (and thus, must allow multiple instances 
of particular entries), and if we don't want to archive the state of 
the feed, then we don't need a separate archive document type.  The 
latter seems likely to be supported by the WG, but the former does not. 
  I'd rather have an archive document type, and not repeat entries in 
"normal" feeds.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 7 Feb 2005 12:26:06 -0500

Antone Roundy wrote:
> number for a later revision be greater than the number for an
> earlier revision, but skipping numbers is allowed.
	Providing an explicit revision number exclusively in atom:archives
has both advantages and costs.
	If we assume that revision numbers start at 0 or 1 and increase
monotonically, then revision numbers gets us:
	1. The ability to name or explicitly identify different versions of
an entry.
	2. The ability to determine the order in which entries were written
-- independent of document order.
	3. The ability to detect "missing" entry versions.
	The cost of the three benefits above is, of course, the increased
complexity that comes from needing to maintain the version number associated
with an entry. Given that "revision" is an attribute which is not to be
stored in a normal feed document, this means that the feed document itself
cannot be used as the primary entry storage mechanism -- as is the case in
some systems today. In order to maintain revision numbers, a site that
provided an archive would have to have storage/memory external to the feed
document. The feed document could not be considered a complete
representation of even the current the state of the feed since part of the
state of the feed (the revision numbers of the current entries) would be
stored externally to the feed.

	The first two benefits of version numbers can be had without a
requirement for maintaining any state if we make the version number a
DateTime. The requirement for saving state external to the feed document
could be removed by simply permitting the revision number to appear in the
feed document.
	Is the third benefit -- detection of missing entries -- worth the
cost of requiring that state be maintained? Is it worth it in light of the
fact that a "stateless" alternative exists that provides all the other
benefits?
	Is a revision attribute such a "bad thing" that it is really
necessary to increase the complexity of the system by requiring that it be
stored and maintained external to the feed document itself? Wouldn't it be
easier to just allow sites that archive to include the revision number in
their feed documents?
	Given the two arguments above, it would seem that atom:modified
(must be updated on the change of any byte in an entry) would provide all of
the benefits that appear to be desired with the exception of "missing" entry
detection. 
	Of course, if we went a step further and said that the unique
identifier for an entry was the concatenation of atom:id + (atom:revision OR
atom:modified), then we would no longer require the archive document type at
all...
	But, I won't go there... 

		bob wyman

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 09:31:35 -0800

Hmm... ok, at this point we have a point of disagreement.  I see 
archiving individual entries as being more important (or at least 
equally important) as archiving feeds.

Example: my weblog is a collection of entries, not a collection of 
feeds.  The feed published by my weblog is just a snapshot of a given 
point in time designed to allow others to read my entries without 
visiting my site.  When I archive, what I want to archive are the 
entries, not the feed.  <archive><feed /><feed /></archive>  does not 
make any sense to me.  <archive><entry /><entry /></archive> does. 
(ignore the angle brackets for now, I'm not trying to promote the idea 
of the archive element, I'm just illustrating my point).

Now, if I had my way, I would *probably* spec this out as:

* Archives work fundamentally on the entry level.
* An archived entry consists of all versions of the entry.
* Feeds are only archived as they relate to archived entries. For 
example, if a given entry has an associated comments feed, or some form 
of nested discussion feed, etc.  Such feeds are logically considered 
part of the metadata of the entry.

- James M Snell

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 12:38:57 -0500

Antone Roundy wrote:

> particular resource, then archiving the states of an entry would require 
> the feed to be split into more, smaller feed documents any time an entry 
> is edited without many other entries being published in between edits.  
> For example, if you published an entry, decided to revise a paragraph 
> and published again, found a misspelling and published again, and then 
> fixed and published another misspelling, you'd need four documents, two 
> of which would only contain one entry.  Doable, yes.  But a little ugly.
> 

No, I'm saying I would regenerate a feed with every entry in it every 
time I make a change. Then, I would check it into Subversion.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Mon, 07 Feb 2005 12:31:18 -0500

> here at the last minute is not going to be completely adequate.

The word "archive" shouldn't have been in the charter. Since no one even 
bothered to define the term over the past 8 months, I will do it now.

Archiving -- It must be possible to serialize a complete collection of 
entries using the Atom Format.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 10:48:35 -0700

Collecting a bunch of recent discussion into one document, how about 
these for a set of terms and their meanings:

* Entry: An abstract term describing a unit of content and metadata 
associated with it.
* Entry Representation: A representation of a particular state of a 
particular entry.
* Entry Document: A document, whose document element is <entry>, which 
contains a single Entry Representation.
* Feed: An abstract term describing a stream of Entry Representations.
* Feed Document: No such thing--replaced by Collection Documents and 
Archive Documents.
* Collection: Entry Representations of the current states of the 
Entries from a Feed.
* Collection Document: A document, whose document element is 
<collection>, which contains a Collection or a portion of a Collection.
* Archive: Entry Representations of the historical states of the 
Entries from a Feed.
* Archive Document: A document, whose document element is <archive>, 
which contains an Archive or a portion of an Archive.  Archive 
documents may contain multiple Entry Representations of the same Entry.

Publishers may choose to publish only Collection Documents, only 
Archive Documents, only Entry Documents, or any combination of these.  
So, for example, a publisher who does not track the historical states 
of their Entries might publish only a Collection Document.  A publisher 
who DOES track the historical states of their Entries might publish 
only an Archive Document, or both Collection and Archive Documents, or 
only a Collection Document.

Processing an Archive Document would be slightly more complicated than 
processing a Collection Document for clients that don't track the 
history of a Feed--for example, scripts that simply display the current 
contents of a Document on a website, because they might need to choose 
one from among multiple Entry Representations of the same Entry for 
display or other processing.

---

From: James M Snell <[email-masked]>
Date: Mon, 07 Feb 2005 09:49:33 -0800

Yuck. I don't like the granularity of that at all.  I can see checking 
in individual entries, but not a single feed with every entry. What if 
I'm just changing the value of a single title attribute? Should I have 
to regenerate the entire feed and check in the entire feed just to 
update the archive for one minor edit?  That would be kind of like 
taking all the source code for a given project, zipping it up into a 
single zip file and checking that into subversion.  Sure, it would work, 
but dang that's nasty (not that it's not being done).  Better to archive 
individual entries.  Sure, archiving of feeds can be done also, but 
archiving feeds is separate from archiving entries.  They are separate 
documents, treat them separately.

- James M Snell

Robert Sayre wrote:
>> require the feed to be split into more, smaller feed documents any 
>> time an entry is edited without many other entries being published in

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 11:11:33 -0700

On Monday, February 7, 2005, at 10:26  AM, Bob Wyman wrote:
> with an entry.
Only if the version number for a particular Entry Representation needs 
to remain constant.  I'd be fine with it either way--simplicity and 
only #2 (and limited #1--you can do it within the context of a 
particular instance of the archive, but can't be sure it won't change 
when you download the archive again) vs. storing the version number and 
getting all 3.

> DateTime.
Of course, you'd have to store the DateTime.  It's more likely that 
people are already doing that, so for those that are, this would be 
preferable.  Those who aren't are likely not storing the historical 
states of the entry at all.

> easier to just allow sites that archive to include the revision number 
I'd have no problem with allowing that.

> the benefits that appear to be desired with the exception of "missing" 
True.  Rather than going back into the whole discussion of dates, we 
could let people who want to get benefits #1 and #2 can store 
dc:modified (since atom:modified) doesn't currently exist, and those 
who don't do that can either invent their own extension like @revision. 
  So archive documents as defined in Atom wouldn't include either, and 
the market would show us which would prevail.

I'm feeling a little apathetic about exactly how we do it at the moment.

---

From: [email-masked] (John Panzer)
Date: Mon, 07 Feb 2005 09:36:52 -0800

> don't see why we need atom:archive after all.
+1 [1]. Specifically, I think that we can fulfill the charter's 'support 
for archives' requirement [2] with the existing syntax plus the 
facilities provided by the protocol.  How an archive is stored is 
something I'd be happy leaving to 'archiver' implementations in much the 
same way we leave such details to 'aggregator' implementations.  I can 
certainly see value in standardizing document formats for archivers to 
allow interoperability; but I don't think the benefit is worth the cost, 
and I don't think the charter requires it.

-John

[1] Though I actually disagree that just a series of feed documents 
makes an archive -- what about non-entry resources?  Where are my cat 
pictures?
[2] At least for the types of archives I think are important.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 7 Feb 2005 14:00:21 -0500

Antone Roundy wrote:
> [polling] would result in bandwidth usage being spread over time 
> everyone as quickly as possible after they're published.
	At PubSub, we operate both a push and a pull service. We know from
experience that the push service results in drastically less bandwidth per
user then the polling service does. This is not based on theory -- rather
the statement is based on real empirical evidence of running both services
side by side. The bandwidth savings of the push service comes from the fact
that we don't have to handle the poll requests themselves and we never
publish the same item twice to a single subscriber as is inevitably the case
with a multi-entry polled RSS/Atom file.
	In order to demonstrate polling at its most efficient, I defined and
convinced a number of folk to implement RFC3229+feed. This HTTP extension
eliminates the problem with sending multiple copies of messages to people
and the resulting drop in bandwidth requirements for those who poll and use
RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still
consumes more bandwidth then the push service. Once again, this ain't
theory, it is experience.

> I've lost track of what aspect of Atom's architecture you 
> are saying is bound to polling at the expense of push.
	There are several "Feed-oriented" or "polling oriented" discussions
going on:
	1. The requirement that feeds not be permitted to contain multiple
entries that have the same atom:id. This requirement prevents push based
system from using feeds as "logs" or "histories" of messages sent. For
instance, at PubSub, the Atom file which is associated with every
subscription contains a stream of entries that are the entries that either
were or would have been sent to the client if it had been connected. The
first thing a client does on starting up is to read the Atom file in order
to synchronize state with the server. Thus, the feed is actually just a
trace of the messages sent. This probably sounds weird if you're
feed-focused; however, it makes perfect sense if you are pushing entries.
	2. Significance of the order of entries in feeds. A push-fed client
only sees feeds in edge cases (like the PubSub synchronization usage
discussed above). Because a push-fed client receives a stream of entries --
not feeds, it can only see chronological order unless order is encoded
within the entry itself. Any requirement that document order is significant
(and some are still suggesting it is) means that a push-based system must
push entire feeds rather then individual entries. The bandwidth costs of
doing so would be completely unacceptable. (Things like ordered lists should
be handled by having entries that contain ordered lists. Exploiting the
anecdotal attributes of the atom:feed document and the practices of current
aggregators is NOT reasonable.)
	3. The absence of a revision id or atom:modified. The feed-ists
don't see the need for revision numbers in part because they are focused on
feeds rather than entries. If you live in the world of entries -- as a push
system does -- then the need to distinguish multiple versions of the same
entry becomes much, much more important.

	I have an additional set of concerns that are based on our
experience as generators of aggregate feeds. The problem is that we are at
the mercy of the creators of feeds... The rules say, as they should, that
we're not supposed to change the atom:id of something that we extract from a
feed. Thus, when we generate results, we should use the atom:id's that we
found in the source entries. However, if someone fails to create really
unique atom:id's, we are left wondering what to do... We aren't supposed to
generate a feed with repeat atom:id's according to the spec, however, our
users will want to see all entries that match their search terms. We have to
either conform to the Atom spec by dropping one of the Entries from the
results -- and thus serve our users less well, or, we have to generate new
atom:id's in order to serve our users but violate the specification. In
other words, we can't win.
	Similarly, the prohibition against multiple instances of an atom:id
means that we can't implement a "show me all versions" feature using Atom as
the packaging format for the results. (No, we're not planning to do this.
But, it would be good to be able to do it.)

		bob wyman

[1] http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html

---

From: Antone Roundy <[email-masked]>
Date: Mon, 7 Feb 2005 12:42:10 -0700

> theory, it is experience.
You are of course the one in a position to know about this.  I'm 
curious though--do you have figures on how much push reduced bandwidth 
use vs. RFC3229+feed?  My guess would be that the difference wouldn't 
be as dramatic as between feed and RFC3229+feed, but I recognize that I 
may be wrong.  That guess is what I was expressing.

> feed-focused; however, it makes perfect sense if you are pushing 
It doesn't sound particularly weird, though I don't understand why the 
typical client would feel the need to see obsolete representations of 
entries that had been changed more than once while they were offline.  
I fully agree that we should not lock out the option of including 
multiple instances of an entry in some kind of Atom Document.  But I 
also don't think that we should require all Atom Documents (other than 
Entry Documents) to do so.  In other words, I don't think this is an 
either-or question--I think both should be possible.

> doing so would be completely unacceptable.
Agreed.

> entry becomes much, much more important.
Makes sense.  I personally have come to like the idea of using 
dc:modified rather than defining atom:modified.  (I am a proponent of 
atom:updated because there is no Dublin Core equivalent for it).

---

From: Henry Story <[email-masked]>
Date: Mon, 7 Feb 2005 21:10:53 +0100

I think that the complexity that this proposal is proof of its failure.

If you look at a Feed document as simply a sliding window view into
the historical state of entries instead a sliding window view into the
current state of entries (though as I have shown these can overlap),`
then you have your archive document already.

HELLO GUYS/GALS YOU ARE THERE AT THE FINISH LINE. IT ALL WORKS!

One of the arguments against the sliding window view in the historical
state of entries is that it was too complicated. But clearly not going
that way is making things WAY MORE COMPLICATED.

So before proceeding any further it may be worth now comparing the
complexity of both proposals in detail. My guess is that the historical 
one is just a little surprising, but that is all.

Henry Story

---

From: Henry Story <[email-masked]>
Date: Mon, 7 Feb 2005 21:15:51 +0100

On 7 Feb 2005, at 18:29, Antone Roundy wrote:
> The latter seems likely to be supported by the WG, but the former does 
> not.  I'd rather have an archive document type, and not repeat entries 
> in "normal" feeds.

I don't think the historical sliding window view forces you at all
to duplicate the entries in your feed. The spec allows you to remove 
all the old versions if you wish. After all the Present time, is just
one element in the sequence of history.

People who only want to live in the present don't negate history. They
just don't remember it.

Henry Story

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 07 Feb 2005 23:27:01 +0000

> then you have your archive document already.

Choice of model will not make an iota of difference to the core spec. I 
could sit here and claim that sliding window makes reordering impossible 
- that would be about as jaundiced and prejudicial a view as I've seen 
spat out about current state. What good is this doing?

Can we please desist from arguing over models? Five years out we can 
determine if there is a sufficiently powerful model to explain 
syndication based on the data. Not now.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 7 Feb 2005 18:50:17 -0500

Antone Roundy wrote:
> do you have figures on how much push reduced bandwidth 
> be as dramatic as between feed and RFC3229+feed, but I recognize that
> I may be wrong.
	Sorry, we don't have precise numbers. I've done the calculations in
the past (it's a fairly expensive process) but then haven't kept the
detail... I did the calculations for me, not for review or publication. But,
you are absolutely correct in your guess that the savings of push over
RFC3229+feed is less dramatic then the savings over the normal file polling.
This was one of the motivations for our proposing RFC3229+feed in the first
place. We wanted to make polling as efficient as possible since we get
polled a lot and since we poll a lot... RFC3229+feed diminishes the
bandwidth savings you get from push but doesn't eliminate those savings.
That weakens the argument for push, but results in improving the overall
system.

> But I also don't think that we should require all Atom Documents 
> (other than Entry Documents) to do so.  In other words, I don't think 
> this is an either-or question--I think both should be possible.
	I agree that this should not be "either-or". I would be happy if the
spec said something like "multiple entries with the same atom:id MAY appear
in a single feed document." I don't think it would be reasonable to insist
that people insert all changes in their feeds. My goal is simply to permit
this, not force it. Whether the feed contains all versions of entries should
be up to the feed writer.

		bob wyman

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Feb 2005 16:49:59 -0800

> I wonder if you read the rest of my message...

Yes, though it seems to me that you swapped the meanings of
funcId and equivId somewhere between your definitions and your
example, so I lost interest.

> I gave an example that did not conflict with a reasonable design.

On the contrary, you gave an example in which a feed contained
two entries with the same id (where id here is defined as meaning
the author intends this entry to supplant any prior entries with
the same id).  It is not reasonable to include more than
one entry with the same id within the same feed representation,
since all entry representations in the feed representation must
validly represent the state of the feed at the time that the
feed representation was generated (otherwise, it is not a feed
representation at all -- it is an archive, history, ... whatever).

This whole discussion presumes that it is not desirable to send
all versions of all entries as part of the feed; i.e., the author
specifically intends old versions of an entry to never appear in
later versions of the feed.  If you don't agree with that
presumption, then I think you are talking about something other
than what most bloggers call a feed.

> me a lot of time.

Okay, but only if you promise not to extend this discussion on
the atom list -- take it elsewhere if you wish to puncture my
opinion -- atom should be allowed to progress in peace without
invoking the defenders of RDF universality.

<http://www.w3.org/TR/rdf-mt/#intro>:

    There are several aspects of meaning in RDF which are ignored
    by this semantics; in particular, it treats URI references as
    simple names, ignoring aspects of meaning encoded in particular
    URI forms [RFC 2396] and does not provide any analysis of
    time-varying data or of changes to URI references. It does not
    provide any analysis of indexical uses of URI references, for
    example to mean 'this document'. Some parts of the RDF and RDFS
    vocabularies are not assigned any formal meaning, and in some
    cases, notably the reification and container vocabularies, it
    assigns less meaning than one might expect. These cases are
    noted in the text and the limitations discussed in more detail.
    RDF is an assertional logic, in which each triple expresses a
    simple proposition. This imposes a fairly strict monotonic
    discipline on the language, so that it cannot express
    closed-world assumptions, local default preferences, and
    several other commonly used non-monotonic constructs.

RDF has no capacity for temporally qualified assertions, no
conceptual understanding of sink-like services, and very little
habit of distinguishing between resources and representations
(though it does have the capacity to deal with representations
as b-nodes).  Likewise, it does not differentiate between
identification and use, which means it cannot be used to describe
the many times in which a single URI can be used for many
different things even if it only identifies (directly) one thing.
The same comments apply to OWL.

As previously stated, understanding the meaning of a resource
is all about time.  Trying to describe the Web without that
dimension is a hopelessly futile effort that leads to such
absurdities as declaring some URIs as being "invalid" or
"inappropriate" simply because their use does not fit the
artificial model of a timeless world.

> But I can't just take your word for it, as there
> just as senior or more senior positions than your are.

My position is not based on seniority.

> But perhaps

No, as far as I know, there have been no recent developments that
would cause the semantic web to reconsider its central assumptions.

Cheers,

---

From: Henry Story <[email-masked]>
Date: Tue, 8 Feb 2005 08:39:28 +0100

If you just want to stick to syntax, then please leave the pace
as it is. Don't try to impose a model through syntax and then
argue that people can't argue about the model that you are
surreptitiously trying to introduce.

The current syntax (allowing multiple ids in a feed per feed document)
worked very well for both models.

Henry Story

On 8 Feb 2005, at 00:27, Bill de hÓra wrote:
> Choice of model will not make an iota of difference to the core spec. 
> I could sit here and claim that sliding window makes reordering 
> impossible - that would be about as jaundiced and prejudicial a view 
> as I've seen spat out about current state. What good is this doing?
>

---

From: Henry Story <[email-masked]>
Date: Tue, 8 Feb 2005 10:58:30 +0100

> example, so I lost interest.

Well I just looked very carefully again at the mail and though
I found plenty of places I could have expressed myself better, I
did not see any swapping as such take place.

> two entries with the same id

the same funcId to be clear, but two equivIds. It is equivIds that
are the ones you are thinking of, and that have the limitations you
mention: there cannot be two entries in a feed document that have
the same equivId but that are in any other way different, on pain
of the document being self contradictory. Hence I did not make
a document with two equivId entries.

What I wished to show is that you are correct about equivIds, but
that another type of id exists (funcIds) that are less strict and
that don't have the same consequence. There can be more than one
entry in the same feed document with the same functId and with
differing content, without there being any contradiction.

> (where id here is defined as meaning

Worse!: A document with two entries with the same equivId but different
content is inconsistent. It is not an archive, history or anything
else.

Let me proove this. Consider the following example I used at the
end of my lengthy post, but with the funcId replaced by equivIds.

<feed>...
   <entry>
     <title>Atom-Powered Robots Really Run Amok!</title>
     <equivId>vemmi://example.org/2003/32397</equivId>
     <updated>2005-02-07T09:30:02Z</updated>
   </entry>
   <entry>
     <title>Atom-Powered Robots Run Amok</title>
     <equivId>vemmi://example.org/2003/32397</equivId>
     <updated>2003-12-13T18:30:02Z</updated>
   </entry>
</feed>

Now let me model this again in arrow notation because
it is relatively easy to understand and to visualise
(I could do it in prose too, but would be certain to
loose your attention before the first sentence)

_feed
|-entry->_e1
|        |--title-> "Atom-Powered Robots Really Run Amok!"
|        |--equivId-> <vemmi://example.org/2003/32397>
|        |--updated-> "2005-02-07T09:30:02Z"
|-entry->_e2
          |--title-> "Atom-Powered Robots Run Amok"
          |--equivId-> <vemmi://example.org/2003/32397>
          |--updated-> "2003-12-13T18:30:02Z"

because equivId is an equivalence relation [1], it is reflexive [2]
and so for all Entry or Feed objects ef, ef equivId ef. The above
graph therefore entails [3] the graph:

_feed
|-entry-> <vemmi://example.org/2003/32397>
|        |--title-> "Atom-Powered Robots Really Run Amok!"
|        |--equivId-> <vemmi://example.org/2003/32397>
|        |--updated-> "2005-02-07T09:30:02Z"
|-entry-> <vemmi://example.org/2003/32397>
          |--title-> "Atom-Powered Robots Run Amok"
          |--equivId-> <vemmi://example.org/2003/32397>
          |--updated-> "2003-12-13T18:30:02Z"

We can simplify the graph by removing the superfluous
equivId statements.

_feed
|-entry-> <vemmi://example.org/2003/32397>
|        |--title-> "Atom-Powered Robots Really Run Amok!"
|        |--updated-> "2005-02-07T09:30:02Z"
|-entry-> <vemmi://example.org/2003/32397>
          |--title-> "Atom-Powered Robots Run Amok"
          |--updated-> "2003-12-13T18:30:02Z"

And now we since the two groups of entries are speaking
about the same resource <vemmi://example.org/2003/32397>
we can compact the graph down to

_feed
|-entry-> <vemmi://example.org/2003/32397>
          |--title-> "Atom-Powered Robots Really Run Amok!"
          |--title-> "Atom-Powered Robots Run Amok"
          |--updated-> "2003-12-13T18:30:02Z"
          |--updated-> "2005-02-07T09:30:02Z"

Now the problem is that our ontology [4] imposes a restriction
on the number of titles and update dates an entry can have. The
limitation is: they can only have one. The above assigns them
two of each. So if we combine the above graph with the ontology
which it is loaded with we have our contradiction. We cannot
proceed.

If instead of having equivId in the above xml you have funcId
then the first entailment is not possible, and so we don't have
a contradiction. These are just very different concepts, though
they can both correctly be thought of as identifiers.

> than what most bloggers call a feed.

What I am interested in, as a feed reader, is an automatic way of 
getting to know about the changes to content that occur on a site.
Sometimes I will be interested in the history of changes, sometimes
not. Some services will be interested in providing me with the history
of changes others not.

FuncId allows people to send just the latest version of their site
if they wish, or the full list of changes. What is the correct thing
to send will depend on the usage of the feed. Why impose an unnecessary
limitation? Certainly we are not such slaves to the past that we limit
what we do for the sole reason that our ancestors did it that way.

> <http://www.w3.org/TR/rdf-mt/#intro>:

Well I don't want to go into a side discussion on such a topic.
I think all I need to point out is that I have been using extremely
simple mathematical concepts to do with binary relations [1][2][3]
that are very easy to understand. The concept of symmetry, transitivity
and reflexivity are taught in France to children age 13. It is clearly
within the grasp of any engineer. As with most great ideas, it is the
simplicity and clarity of their foundations that enable them to go
so far.

By the way I very much enjoyed reading your thesis. [5]

> Chief Scientist, Day Software              <http://www.day.com/>

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

[1] http://en.wikipedia.org/wiki/Equivalence
[2] http://en.wikipedia.org/wiki/Reflexive_relation
[3] http://en.wikipedia.org/wiki/Entailment
[4] see http://www.intertwingly.net/wiki/pie/AtomOWL
     but it is also clear from the syntax that these restrictions
     apply
[5] http://www.bblfish.net/blog/page1.html#10

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 10:40:43 +0000

> surreptitiously trying to introduce.

Henry, I have no idea what you are talking about.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Tue, 8 Feb 2005 13:42:37 +0100

> Henry, I have no idea what you are talking about.

I think all Henry's referring to is the implicit model - only so much
is made explicit in the spec. There's the "obvious" containership
semantics of XML, there are also plenty of assumptions being made
about server/client architectures. Bits over the wire are useless on
their own, when semantics are to be attached to them there is benefit
in them being standardised through specs.

However even if there was the will to define a model, I can't see it
happening in the time frame for Atom 1.0. Getting something in an I-D
later for RDF-based interop should benefit the core, even without
tight spec coupling. But don't let's kid ourselves what we have right
now is much more than a syntax and a model with
ArchitectureByImplication [1].

10/10 for the Pace title, btw ;-)

Cheers,
Danny.

[1] http://c2.com/cgi/wiki?ArchitectureByImplication

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 08 Feb 2005 13:02:10 +0000

Danny Ayers wrote:
> is made explicit in the spec. 

Oh no, is this one of those "do buildings have an intentional or 
extensional architecture or both" conversations? [I see your link now: 
yes it is. Damn.]

Anyway Henry seems to think I'm trying to impose a model (whatever it 
is). Otherwise why would he tell not me to impose it? That's why I said 
I have no idea what he's talking about. Henry, mindreading objection 
from me.

> There's the "obvious" containership
> semantics of XML, 

XML has containership semantics? You jest methinks.

> But don't let's kid ourselves what we have right

Fine, that's all fine - I'm not looking to kid anyone - I just don't 
care too much about what implicit model people happen to see from day to 
day, as I don't think it matters much to the format. If people willfully 
want to polarize themselves over some pet model, then they can have at, 
but not at the cost of shipping this spec. Has it occured that dragging 
this WG through an explicit model think-fest might not be helpful at 
this point?

> 10/10 for the Pace title, btw ;-)

Thank you.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Tue, 8 Feb 2005 14:13:58 +0100

Thanks Danny, that was a good summary.

+1 for the title from me too.

But I think the deadline for new paces has already passed.  >:->

Henry