Subject: PaceRepeatIdInDocument solution

From: Henry Story <[email-masked]>
Date: Fri, 18 Feb 2005 18:15:38 +0100

The PaceRepeatIdInDocument tries to set the constraints in the
Identity construct whereas the constraint should have gone on the
individual elements.

Instead I would replace the following in the spec:

------------
4.5 The "atom:id" Element

The "atom:id" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed.
------------

with

------------

4.5 The "atom:versionId" Element

The "atom:versionId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed. There 
can only be one entry
per feed document with the same id.

4.6 The "atom:entryId" Element

The "atom:entryId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed. There 
can be more
than one entry per feed document with the same id.

------------

Note:
atom:versionId is the what I have called elsewhere the equivalence id 
relation
atom:entryId is what I have called the functional id relation

The above will allow the feed format to also be used as an archive 
format
if needed.

It clearly distinguishes the two types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate 
one
way and others tried to disambiguate the other way.

As such it correctly resolves an ambiguity by allowing both options.

Henry Story

Ps. text above written quickly cause I have to go do some exercise.

---

From: Henry Story <[email-masked]>
Date: Fri, 18 Feb 2005 19:19:52 +0100

I was not able to go and do the exercise I wanted to do, so here is a
more carefully worded version
------------------------------------------------------------------------

The id construct in atom is ambiguous between two meanings. Since the
two meanings are orthogonal and not incompatible when properly 
distinguished,
the best solution is to distinguish them and allow both.

I would replace the following text in the spec:

------------

with

------------

The "atom:versionId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed version. 
There can only be
one entry  with the same versionId per feed document. There can be only 
one feed
document with the same versionId.

4.6 The "atom:id" Element

The "atom:entryId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed. There 
can be more
than one entry per feed document with the same id. And there can be 
multiple
feed documents with the same id.

------------

Note:
atom:versionId is what I have called elsewhere the equivalence id 
relation
atom:entryId is what I have called the functional id relation

It clearly distinguishes the two types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate 
one
way and other Paces tried to disambiguate the other way.

Henry Story

---

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

Allowing more than one version of the same entry in a syndication feed 
is unacceptable in itself, which is fundamentally incompatible with 
archive feeds, no matter what the conceptual definition of id is.

Graham

---

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2005 11:02:32 +0100

I think I can prove that the two versions are perfectly compatible and 
orthogonal. I can prove that logically there is no inconsistency, and
some empirical backing that this is feasible. But I am not alone. Bob
Wyman I believe has a lot more empirical support.

You on the other hand, as usual I notice, have absolutely no argument to
defend your case.

Henry Story

---

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

>> Allowing more than one version of the same entry in a syndication 
>> feed is unacceptable in itself, which is fundamentally incompatible 
>> with archive feeds, no matter what the conceptual definition of id 
>> is.
>>
>> Graham

Let me make my point even clearer. If something is "fundamentally 
incompatible",
then it should be *dead-easy* to prove or reveal this incompatibility.

So develop your thought a little, and you can only come out the winner.

Henry

---

From: Graham <[email-masked]>
Date: Sat, 19 Feb 2005 15:46:35 +0000

> then it should be *dead-easy* to prove or reveal this incompatibility.

i) Syndication documents shouldn't ever contain multiple versions of 
the same entry*.
ii) Archive documents apparently need to be able to contain multiple 
versions of the same entry.

* for the simple reason that it makes them an order of magnitude harder 
to process and display correctly (and often impossible to display 
correctly, since it won't always be clear which is the latest version).

Your wittering on about conceptual models doesn't make you better than 
us.

Graham

---

From: "Roger B." <[email-masked]>
Date: Sat, 19 Feb 2005 12:54:51 -0600

> i) Syndication documents shouldn't ever contain multiple versions of

Graham: +1.

> versions of the same entry.

I don't even buy that much, personally.

--
Roger Benningfield

---

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

> correctly, since it won't always be clear which is the latest version).

Think of a feed as a stream of entry instances (not hard to do), and process
accordingly. The same thing with a feed document. Whether you read from the
top of the document to the bottom, or vice versa, shouldn't matter - you can
identify the more recent entry by atom:updated. If two instances with the
same atom:id have the same atom:updated, then there is no significant
difference between the two, so go with a random choice (that's not hard
either) (and lobby for atom:modified while you're at it).

For feed readers that already support entry persistence and entry
replacement when an entry is updated from one document to the next, why is
this an order of magnitude more difficult to do in the one document?

e.

---

From: Graham <[email-masked]>
Date: Sat, 19 Feb 2005 23:40:13 +0000

On 19 Feb 2005, at 11:06 pm, Eric Scheid wrote:

> If two instances with the same atom:id have the same atom:updated, 
> then there is no significant difference between the two, so go with a 
> random choice

*that the author considered significant*. If you've told the use 
they're getting the latest version, and they see something else, that 
doesn't fit my definition of working correctly. A paradigm where the 
instance in the feed is always the newest version works much much 
better.

> this an order of magnitude more difficult to do in the one document?

I was talking about feed readers that don't.

And even those that do, you now need to look for duplicates within the 
feed instead of just comparing the new set to the old set. ie Instead 
of removing duplicates that exist between set A and set B, I now also 
have to look within set A as well. You seem to have suggested earlier 
that entries be added to the store one by one. This is not possible in 
Shrook because of the various layers of idiot proofing.

Graham

---

From: Henry Story <[email-masked]>
Date: Sun, 20 Feb 2005 01:35:43 +0100

On 19 Feb 2005, at 16:46, Graham wrote:
> * for the simple reason that it makes them an order of magnitude 
> harder to process and display correctly (and often impossible to 
> display correctly, since it won't always be clear which is the latest 
> version).

I don't accept that it makes it an order of magnitude harder to process 
these
documents, or if it is an order of magnitude harder, its an order of 
magnitude
larger than an infinitesimal amount, which is still an infinitesimal 
amount.
I am writing such a tool, so I think I have some grasp on the subject.

But accepting for the sake of argument that you are right, you need 
compare the difficulty of writing a feed reader with the difficulty of 
writing a feed
itself. Not allowing duplicate versions of an entry in a feed just 
pushes the
complexity of writing the feed from the feed reader to the feed writer:
now the feed writer has to contain the logic to make sure than no 
duplicates
appear in the feed.  Instead of the feed writer just being able to 
paste the
new entry to the end of the feed, it has to parse the whole feed 
document
and make sure it contains no duplicates.

Since I can see very good reasons to make life easier for the feed 
writer, in the
same way as one has tried to keep html simple for the common html 
writer, I
think your argument may in fact turn out to be a good supporting 
argument for
allowing multiple versions of an entry in the same feed document.

> Your wittering on about conceptual models doesn't make you better than 

I never pretended it does make me better.

I have been exploring tools such as rdf, as I believe that they can 
bring a
lot of clarity to debates such as this one. Just as engineers don't 
hesitate
to use mathematics to help them in their tasks, so I think using logical
analysis should help us here. I hope that as I understand these tools 
better
I will be able to explain the insights these disciplines bring in 
plainer
english.

In the mean time I have a lot of respect for Tim Berners Lee, and
I try my best to understand the direction he is going in, the tools he
is developing and the insights these lead to.

Henry Story
http://bblfish.net/

---

From: Eric Scheid <[email-masked]>
Date: Sun, 20 Feb 2005 12:27:48 +1100

On 20/2/05 10:40 AM, "Graham" <[email-masked]> wrote:

>> If two instances with the same atom:id have the same atom:updated, then there
>> is no significant difference between the two, so go with a random choice
>> 
> *that the author considered significant*. If you've told the user they're
> getting the latest version, and they see something else, that doesn't fit my
> definition of working correctly.
> 

Like I said, lobby for atom:modified.

hmmm ... looking back in the archives I see you were opposed to
atom:modified, you couldn't see any use case where you would want the entry
instances to clearly indicate which is more recent. Hashes won't help you
here.

Is this where I say "told you so"? ;-)

> A paradigm where the instance in the feed is always the newest version works
> much much better.
> 

A paradigm that fails completely once a reader starts traversing
@rel="prev", or they have a planet aggregator in their subscriptions which
has fallen behind due to ping lags.

"the newest version" is something which should be publisher controlled, not
left to the variable circumstances of protocol happenstance and
idiosyncratic personal subscription lists.

>> For feed readers that already support entry persistence and entry replacement
>> when an entry is updated from one document to the next, why is this an order
>> of magnitude more difficult to do in the one document?
>> 

OK, lets look at feed readers that don't then ... first off, generally
speaking, you're unlikely to find a feed instance which does contain
multiple entries with the same id, and if you did it would be because that
is how the publisher wants it. The publisher wants both instances available
for reading, who are you to conflate the two? If there is some broken [1]
publishing software out there then readers will complain to the publisher
(if they complain to you, say "that's how the publisher wants it").

Secondly, there is that use case where an archive of all versions of an
entry is provided in a feed. This is provided so users can see all previous
versions of the entry ... is it so bad then that a naïve feed reader would
then display all versions of that entry?

e.

[1] do you know of any publishing software which currently emits feeds with
multiple instances of entries? I can't think of any.

---

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

> instances to clearly indicate which is more recent. Hashes won't help 

Yes, if you want multiple versions you need atom:modified. I oppose 
both.

> @rel="prev"

Not if the url in the prev is properly thought through; ie instead of 
asking for "page 2" the uri query asks for "entried before n", where n 
is the oldest entry number in the page before.

Anyway, rel="prev" doesn't exist last time I checked.

> or they have a planet aggregator in their subscriptions which

Are there really aggregators naïve enough to take an entry with the 
same id from one feed and paste over the last retrieved entry from 
another? There are far more problems with that before you start 
worrying about what is the latest entry.

> idiosyncratic personal subscription lists.

or "picking randomly", as you suggested not 2 emails ago.

> OK, lets look at feed readers that don't then [etc]

This is where Eric dictates how other people's feed readers should work 
to fit the flaws in his preferred proposition.

> multiple instances of entries? I can't think of any.

None. That's why it should be explicitly barred, since no software is 
expecting it.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 19 Feb 2005 23:07:42 -0500

Graham wrote:
>> [1] do you know of any publishing software which currently emits
>> feeds with multiple instances of entries? I can't think of any.
> None. That's why it should be explicitly barred, since no software
> is expecting it.
	PubSub regularly produces feeds with multiple instances of the same
atom:id. No one has every complained about this to us.
	Given that history shows that publishing repeated ids has never
bothered anyone enough to cause them to complain, we should permit this
benign practice to continue. 
	It is particularly important to avoid prohibiting this benign
practice since it is so important to generators of aggregated feeds.
Aggregated feed generators are supposed to maintain atom:id unchanged when
they copy entries into an aggregate feed. However, the Atom format doesn't
provide rigorous guarantees that atom:id's will be unique across feeds.
Thus, aggregated feed publishers are left with the choice of 1) Trusting
feed publishers or 2) Assigning new atom:id's to all entries published. The
first option will inevitably result in repeated ids and the second results
in massive amounts of work, difficulties in duplicate detection, violation
of the "maintain atom:id" rule, etc.
	Forbidding repeated ids causes damage. History shows, however, that
allowing repeated ids is benign.

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Sun, 20 Feb 2005 15:38:38 +1100

On 20/2/05 1:47 PM, "Graham" <[email-masked]> wrote:

> Yes, if you want multiple versions you need atom:modified. I oppose both.
> 
atom:modified also helps in distinguishing multiple instances found in
separate feed documents.

You oppose atom:modified, and yet you insist on kludging a hack for
identifying which of two entries is the most recent. A hack which isn't even
mentioned in the spec, so gawd help software developers all arriving at the
same hacky solution to the problem.

You opposed it because you couldn't foresee any use case for it, and now you
have a use case for it but you say that that use case should be banned
because you opposed atom:modified.

I forget: is this the circular reasoning logical fallacy, or the begging the
question fallacy?

>> A paradigm that fails completely once a reader starts traversing @rel="prev"
>> 
> Not if the url in the prev is properly thought through; ie instead of asking
> for "page 2" the uri query asks for "entried before n", where n is the oldest
> entry number in the page before.

Where are these special semantics codified into a specification?

Also, define "oldest". Is this the one with the oldest atom:updated, even
though you earlier (and rightly) dissed that because it was "that the author
considered significant". Or is oldest defined by atom:published, which as
you might recall is an *optional* element for atom:entry.

Also, define "number" in "entry number". Entries are not numbered, they have
id's, and while it's often easy to use an incrementing serial that is not
always the case. 

> Anyway, rel="prev" doesn't exist last time I checked.

This does: @rel="http://www.example.org/atom/link-rels#prev", and that's a
valid value for the @rel attribute. There is also no language in the spec
that prevents someone registering "prev" in the Registry of Link Relations.

<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section
.9.1>

So you might as well assume it does exist.

>> or they have a planet aggregator in their subscriptions which has fallen
>> behind due to ping lags.
>> 
> Are there really aggregators naïve enough to take an entry with the same id
> from one feed and paste over the last retrieved entry from another?
> 
Naïve or smart? I subscribe to one feed which is the top headlines for that
site, and I also subscribe to all headlines for one category at that site.
The "naïve" thing to do there would be to not conflate entries with
identical id's.

Another use case: I subscribe to a feed from the publisher's website, but
later he sets up a link at feedburner.com or similar. The naïve thing would
be to assume that all the entries from feedburner.com are completely
different from those retrieved from example.com, despite having the same
id's.

> There are far more problems with that before you start worrying about what is
> the latest entry.
> 
You forget: I determine what entries I subscribe to, as you do for yourself.
If a bad actor starts screwing with id's then I can also unsubscribe.

So, leaving aside hand waving scare-mongering statements like "far more
problems", just what problems are there Graham?

>> left to the variable circumstances of protocol happenstance and idiosyncratic
>> personal subscription lists.
>> 
Glad you agree with me there.

We wouldn't need to pick randomly if we had atom:modified.

> This is where Eric dictates how other people's feed readers should work to fit
> the flaws in his preferred proposition.
> 
A gross sophistry on your part. If you don't want to argue the merits and
prefer ad hominem attacks, then there really isn't much point continuing.

> None. That's why it should be explicitly barred, since no software is

Nonsense. That's like arguing that http agents should only support those
mime-types which were already defined oh so many years ago. No software
currently exists that can possibly be expecting "application/foo", but that
doesn't mean "application/foo" is an illegal mime-type.

e.

---

From: Graham <[email-masked]>
Date: Sun, 20 Feb 2005 05:34:55 +0000

> because you opposed atom:modified.

That's not what I meant. I opposed atom:modified because this use case 
wasn't on the table then. I oppose multiple ids partly because we don't 
have atom:modified. You can't have one without the other.

My real problem with atom:modified is that it's unnecessarily tied to 
the Last Modification Date semantic, when it would work just as well 
for this purpose if it weren't. We just need a date with the constraint 
"date(a)<date(b) whenever entry instance a is older than entry instance 
b". This would make it easier to generate in various scenarios, and 
sidestep the problem of defining what a "modification" is.

> The "naïve" thing to do there would be to not conflate entries with

No, I'm talking about storing the entries retrieved from different uris 
in the same local record and letting them overwrite each other. A 
really smart aggregator would inform the user that they got different 
versions from each place, and let them see both.

> doesn't mean "application/foo" is an illegal mime-type.

No, since the HTTP spec says that any mime type is possible, whereas 
the Atom spec says ids are "universally unique". If it's wrong to then 
think you won't find the same id twice in the same document, the spec 
needs to say so.

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 20 Feb 2005 12:25:08 +0000

Chairs/Editors,

- I think that this discussion (repeat ids) is architecturally 
significant in terms of how Atom layers onto the Web and is best taken 
forward under feed state,

- Feed state discussion ought to deal explicitly with entry state, as 
that's the more difficult case.

Graham wrote:
> in the same local record and letting them overwrite each other. A really 
> smart aggregator would inform the user that they got different versions 
> from each place, and let them see both.
>

Graham, Eric,

My thinking goes like this,

  - Is there a difference between an entry and the chunk of XML you see 
in a feed?

- If there is, it will be in the same way there is a difference between 
a resource and a representation in web architecture.

- If you *don't* think a difference exists between an entry and the 
chunk of XML you see in a feed, there may be things you can't sensibly 
say [1]. For example if we disallow multiple appearance of an id in one 
feed we might as well disallow multiple appearance of an id across all 
feeds, for consistency. That, or document our spec's private definition 
of the word "unique".

- If you *do* think a difference exists between an entry and the chunk 
of XML you see in a feed, there may be some practical limitations. For 
example we will want to ask what's the difference operationally between 
two Entries that have been assigned the same id and the appearance of 
two entries with the same in an Atom document that represent the Entry 
at different states? What's the test that distinguishes between those 
two cases?

- That we can start sending multiple representations of a resource each 
marked as so inside another single representation I suspect extends web 
architecture. I looked and didn't see any support for this idea in AWWW. 
  Whether it's tunneling, abuse, or a new application layer I don't know.

- Maybe the WebDAV folks have been through this. HTTP has no obvious use 
cases or support for serving up resource state in one entity body rather 
than as a stream of entities.

My opinion is that keeping XML representations of entries distinct from 
entries affords the most flexibility and maximises internal consistency 
for the kind of use cases feeds support [2]. It will be an arbitrary 
limitation of language if Atom can't deliver entries with the same id in 
the same feed - I don't believe that limitation will be respected in 
practice. It also means we're (possibly) formalizing something for the 
Web that hasn't been done before.

cheers
Bill

[1] I emphasise 'sensibly say' here rather than 'sensibly do'. Just 
because or spec can't say something doesn't mean people won't try to do 
it if they think they need to.

[2] I spend a lot of time dealing with identity issues in my job. I've 
come to believe that neither unique ids or content based identity or a 
combination of both can eliminate all ambiguities. Sometimes you have to 
guess whether two things are the same no matter what model you're 
working with.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 20 Feb 2005 08:27:03 -0500

> benign practice to continue. 

I have exactly the opposite experience.  I have people who have thanked 
me for noticing that they have repeated ids as it indicated an error in 
their software.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sun, 20 Feb 2005 16:10:27 +0000

On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:

> atom:id.

Which part of "universally unique" didn't you understand?

> they copy entries into an aggregate feed.

This is a fair point. I concede that multiple versions of entries with 
the same id is acceptable if and only if they have different feed ids 
in their head-in-entry, since essentially then they aren't in the same 
feed.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Mon, 21 Feb 2005 03:30:13 +1100

> have atom:modified. You can't have one without the other.

if this use case was on the table back then, and you were to consider the
question in that light, where would you stand?

(actually, we could have atom:modified while still outlawing multiple id's,
but you are right that atom:modified is required to disambiguate if multiple
id's are allowed.)

> sidestep the problem of defining what a "modification" is.

heh -- one way to then generate to fit your requirements would be

    atom:modified := atom:published + sequential-number

that is, increment the atom:modified by one second for every version.

Semantically, it would work ... for comparing two instances of one entry. It
wouldn't work for establishing if an entry was modified before or after
[some event moment] (eg. close of the stock exchange).

As to defining "modification" ... I was writing spec text which attempted
just that ... I was working towards the idea that any changes in values of
atom:entry elements, other than serialisation (including character encoding
and element order), and ignoring any changes in referenced resources.

> No, since the HTTP spec says that any mime type is possible, whereas the Atom
> spec says ids are "universally unique". If it's wrong to then think you won't
> find the same id twice in the same document, the spec needs to say so.

My apologies: I was making an analogy, not providing an example. As such,
ignore the specifics of the analogy. I should have just written "Spec FOO is
silent on X, therefore X is verboten". Which is a nonsense position.

e.

---

From: Henry Story <[email-masked]>
Date: Sun, 20 Feb 2005 17:58:23 +0100

> Which part of "universally unique" didn't you understand?

Ok, I see so you interpret the "universally unique" in

[[
An Identity construct is an element whose content  conveys a permanent, 
universally unique identifier for  the construct's parent. Its content 
MUST be a URI, as  defined by [RFC3986]. Note that  the definition of 
"URI" excludes relative references.
]]

to mean that there can only be one entry in a feed with the same id, and
presumably across all feeds, or else why use the word "universally" and
not "feedally"?

Why could we not then allow another id construct, call it "entryId" that
would be what all entries that are just editorial changes of one another
have in common?

This would be something like:

<feed>
	...
	<entry>
		<id>tag:bblfish.net/entry1/version1</id>
		<entryid>tag:bblfish.net/entry1/</entryid>
		<title>Atom Robots Run Amok</title>
         ...
	</entry>
	<entry>
		<id>tag:bblfish.net/entry1/version2</id>
		<entryid>tag:bblfish.net/entry1/</entryid>
		<title>Atom-Powered Robots Run Amok</title>
         ...
	</entry>
	
</feed>

As you can see in the above feed there are no two entries with
the same id. Yet there are two entries with the same "entryid".

Would the above be an ok feed for you, or are there some other
reasons why a entryid node would be illegal?

> in their head-in-entry, since essentially then they aren't in the same 

So should we replace "universally unique" above with "unique in a feed" 
then?

---

From: Walter Underwood <[email-masked]>
Date: Sun, 20 Feb 2005 09:23:45 -0800

About logical clocks in atom:modified:

> [some event moment] (eg. close of the stock exchange).

Establishing sequences of events is rather tricky. See Leslie Lamport's
"Time, Clocks, and the Ordering of Events in Distributed Systems" for how
to do it with logical clocks. The core part of the paper is short, maybe
five pages, and definitely worth reading if you care about this stuff.

 <http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf>

Synchronized clocks make this simpler. If Atom depends on comparing timestamps
from different servers, then synchronized clocks are a SHOULD. See the text in
PaceCaching for an example.

Synchronized clocks are already a SHOULD for HTTP.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Graham <[email-masked]>
Date: Sun, 20 Feb 2005 18:13:07 +0000

> question in that light, where would you stand?

I like the model where the feed content is approximately "The current 
version of the latest entries". I don't think anything else makes much 
sense, least of all "Various states past and present of various entries 
(some assembly required)".

> heh -- one way to then generate to fit your requirements would be

My idea would be that the originating server would simply stamp entries 
with the current time during feed generation, so if they get mixed up 
in transit by third parties or caches the later version would still be 
known. Note the originating server doesn't have to store or keep track 
of anything.

> and element order), and ignoring any changes in referenced resources.

But that gets complicated to generate cleanly. When you edit your feed 
template you need to do something like:

   if (entry modification date > date template was edited)
      print date template was edited
   else
      print entry modification date

Generating a last modification date according to someone else's idea of 
modification is not pretty.

> silent on X, therefore X is verboten". Which is a nonsense position.

I wouldn't define the phrase "universally unique" as Atom being silent. 
It is massively open to interpretation since the literal meaning is 
nonsense, and I suppose conveying no useful information could be 
interpreted as silence.

Graham

---

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

Graham wrote:
> My idea would be that the originating server would simply stamp 
> entries with the current time during feed generation, so if they
> get mixed up in transit by third parties or caches the later version
> would still be known. Note the originating server doesn't have to
> store or keep track of anything.
	You propose timestamps, yet you oppose atom:modified -- which was
intended to provide precisely the timestamps you suggest. Or, is there
something I am missing? (atom:modified was entry-specific but you seem to be
suggesting a feed-global timestamp...)
	Is the problem in your comment that "the originating server doesn't
have to store or keep track of anything"? Does this imply that your
timestamp is really just the atom:updated of the feed and would change every
time that the feed was updated? If this is the case, should we reword the
definition of atom:updated to say that when it is used as feed metadata, it
MUST be updated every time the feed is changed in ANY way? Should the
"significant change" words only apply to atom:updated in entries? (Note:
Since the feed's atom:updated is an element of Head, this implies that if
HeadInEntry stands, the feed's atom:updated would or could be "in the
entry.")
	If your timestamp is really the same as the feed's atom:updated,
then what is the impact of your proposal on signatures? Would all individual
entries in a feed need to be re-signed every time any change was made to the
feed such as inserting a new entry? Would this be the case even if the
change did not otherwise modify the signed entry? 
	Does your timestamp proposal imply that an entry which appeared in
multiple feeds would have a different timestamp in each feed it appeared?
(Note: That would have the odd effect of tending to make error-prone copies
consistently appear to be the 'last modifications.' One tends to write to
the "main" feed first and then later to "category" feeds... Copies will
generally have timestamps later than the originals.)

> Generating a last modification date according to someone else's
> idea of modification is not pretty.
	Yes! This is the problem that an intermediary in the channel faces.
The intermediary (a proxy, retrospective search engine, prospective matching
engine, etc.) needs to know which entry is the most recent modification.
However, Atom provides no mechanism by which the last modification can be
identified without heuristics. (atom:updated only tells you the time of the
last "significant" modification but that leaves you unable to determine
which of various alternative "insignificant" modifications should be passed
on by the intermediary.
	Without help from the Atom format, the best an intermediary can do
is keep track of "date_entry_was_found". However, this can cause problems
since entries can exist in multiple feeds. Thus, the order in which the
feeds are read can cause old entries to over-write newer ones.
 
		bob wyman

---

From: Graham <[email-masked]>
Date: Mon, 21 Feb 2005 00:39:06 +0000

> suggesting a feed-global timestamp...)

No. As I said earlier, the only property of atom:modified we're 
interested in is:
   date(a)<date(b) whenever entry instance a is older than entry 
instance b"

Let's define an atom:version date element for each entry that has only 
that constraint. You can obviously still use a Last Modified Date to 
fulfil it. But what you can also do is have the originating server 
stamp each entry with the current date and time, and it still works. 
For example, if a client receives an old cached version, it will have 
an older date and can be discarded if an entry with a newer 
atom:version date is already known.

> multiple feeds would have a different timestamp in each feed it 

Yes.

> generally have timestamps later than the originals.)

We're talking serving static files, right? In this case the category 
feeds would still contain the old date they were generated until they 
were updated, preventing them from overwriting newer versions.

Graham

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Feb 2005 09:36:39 -0800

At 12:25 PM +0000 2/20/05, Bill de hÓra wrote:
>significant in terms of how Atom layers onto the Web and is best 
>taken forward under feed state,
>
>- Feed state discussion ought to deal explicitly with entry state, 
>as that's the more difficult case.

My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want 
the model to be different, and most don't care about the differences 
between those two.

When the next draft of the document comes out, this can be rehashed 
again in the WG if there is a single specific Pace that gives a 
complete delta from that draft.

However, that Pace will not necessarily hold up us going to IETF last 
call, unless our AD wants it to. This kind of "does the model say A 
or B" discussion is quite appropriate in IETF last call, where folks 
who have very different model ideas might join in.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 22 Feb 2005 23:18:49 +0000

Paul Hoffman wrote:
> the model the way the document currently reads, other actively want the 
> model to be different, and most don't care about the differences between 
> those two.
> 
> again in the WG if there is a single specific Pace that gives a complete 
> delta from that draft.
> 
> call, unless our AD wants it to. This kind of "does the model say A or 
> B" discussion is quite appropriate in IETF last call, where folks who 
> have very different model ideas might join in.

Ok, my opinions above stand, irrespective of when you think the 
discussion should be scheduled; there's an architectural issue wrt how 
Atom layers Web representations and there are tradeoffs to be 
considered. Anyway, I thought we were done with Paces.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Feb 2005 08:53:02 +0100

>> the model to be different, and most don't care about the differences 

That is a very diplomatic way of putting things :-) since we don't know 
what
you mean by the way the document currently reads.

There was an attempt to resolve the ambiguity of how many times an 
entry with
the same id can appear in a feed document. The resolution of this 
ambiguity in
favor of one model over the other at such a late stage in the game can 
seem
like an attempt by some to impose their reading of the spec.

I would be in favor of not resolving the ambiguity but of highlighting 
it
with text such as

[ whether more than one entry with the same id can appear in a feed 
document
   has not yet been resolved ]

This would have the virtue of not taking sides in the debate and of not
forcing one reading by default.

We can then move onto the protocol issue, which I think will force the
clarification of what an Entry is, and thereby  the arguments as to why
one reading or the other should be preferred.

Henry Story

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 23 Feb 2005 10:03:16 +0000

> you mean by the way the document currently reads.

Ftr, I didn't say that, Paul Hoffman did. Please be careful with your 
attributions!

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 23 Feb 2005 10:07:16 +0000

Henry Story wrote:

> I would be in favor of not resolving the ambiguity but of highlighting it
> with text such as
> 

-1. That is of no little value to a user of the spec. Also, do read what 
I said earlier in this thread - I'm not looking to resolve ambiguity, 
I'm looking to specify what's going to be ambiguous.

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Feb 2005 11:34:32 +0100

Sorry that should have been "Paul Hoffman wrote":

>>> model described in the document differently. Some folks actively 
>>> want the model the way the document currently reads, other actively 
>>> want the model to be different, and most don't care about the 
>>> differences between those two.
>
> That is a very diplomatic way of putting things :-) since we don't 
> know what

Bill de hÓra then responded:

[[
-1. That is of no little value to a user of the spec. Also, do read 
what I said earlier in this thread - I'm not looking to resolve 
ambiguity, I'm looking to specify what's going to be ambiguous.
]]

To which I reply:

This is getting to be a very subtle distinction, and I am having 
trouble following.

I am not trying to resolve ambiguity. The text above is looking to 
point out
in the text what is ambiguous.

The hope is that questions such as the ones you are asking in this 
thread,
and work on the protocol, will help clarify the ambiguity and perhaps 
resolve
it to everyone's satisfaction.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 23 Feb 2005 11:10:46 +0000

Henry Story wrote:

> This is getting to be a very subtle distinction, and I am having trouble 
> following.

If you allow multiple entries with the same id in a feed, there's no 
straightforward way to determine whether the feed provider has defective 
id distribution. All you do is say these entries represent states of the 
same thing.

If you don't allow multiple entries with the same id in a feed, then 
feeds become a special aggregation case since you almost certainly want 
to allow multiple entries with the same id across feeds.

This has to do with webarch because the use case for multiple 
representations (entries) carried inside other representation (feeds) 
and from multiple authorities aren't covered by it, and bring up such 
issues as the above,  eg, I have no idea whether Atom/RSS represents a 
new layer above or an extension to, current app protocols. Aside from 
overall architecture I sepculate that can be expected to have 
implications for trust, caching, security and design of implementations. 
So far we've only really talked about the effect on client aggregators 
in presenting entries to users. *

What's subtle about that? :)

cheers
Bill

* This is the point where I start to see where Rob Sayre is coming from 
with WebDAV.

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Feb 2005 13:09:22 +0100

I like the way you put the question below. It is indeed very clear.

But it does not seem incompatible with us adding some text now in the
spec that acknowledges that we have not yet answered the questions you
pose. I would surround this text  with square brackets [] just as we
have done with other parts of the spec that are not finished. I
certainly prefer this to text being added that suddenly cuts the issues
arbitrarily.

If I follow your reasoning correctly whatever way one cuts this, one is
left with a problem. These problems had not been acknowledged clearly
before, so  there is no guarantee that this group has in fact agreed on
anything with respect to this. The problem therefore does either need to
be resolved or it has to be acknowledged. I propose we acknowledge the
problem in the just-about-to-come-out revision of the spec with language

rather than go the way Tim Bray was thinking of going, namely:

> PaceRepeatIdInDocument
> Lots of discussion, more -1's than +1's.
> DISPOSITION: No consensus, close it.  But now we have a problem, in 
> that this removed ambiguity in one direction, just closing it leaves 
> the ambiguity.  So the only logical conclusion is that the WG is 
> directing the editors to put language in that explicitly forbids 
> entries with duplicate <atom:id> in an <atom:feed>.

I would like to answer your questions below, but I would rather wait to
see where the whole new version of the spec has put us before embarking 
on
the debate.

I gather it should be ready any time now.

Henry Story

On 23 Feb 2005, at 12:10, Bill de hÓra wrote:
> straightforward way to determine whether the feed provider has 
> defective id distribution. All you do is say these entries represent 
> states of the same thing.
>
> feeds become a special aggregation case since you almost certainly 
> want to allow multiple entries with the same id across feeds.
>
> implications for trust, caching, security and design of 
> implementations. So far we've only really talked about the effect on 
> client aggregators in presenting entries to users. *
>
> * This is the point where I start to see where Rob Sayre is coming 
> from with WebDAV.
>