Subject: Refresher on Updated/Modified

From: Tim Bray <[email-masked]>
Date: Fri, 20 May 2005 16:40:56 -0700

I'm engaged in trying to convince a large well-known organization to  
take Atom seriously (I think I'm winning) and we had this email  
exchange, which I thought might be useful as a refresher for those who  
have blissfully forgotten the great updated/modified debate.

======================================================================== 
===========================

> I think the biggest concern right now is that that the LastUpdated  
> date can be left unchanged even when the post IS changed (e.g.  
> spelling corrections)

What you want is reasonable to want but unfortunately no syndication  
format can give it to you.  Here is the current language:

       The "atom:updated" element is a Date construct indicating the
       most recent instant in time when an entry or feed was modified
       in a way the publisher considers significant.

There was a proposal for an "atom:modified" date that was to be updated  
every time any change no matter how tiny was made but it was shouted  
down.  There were many arguments against, but here are three that I  
couldn't think of an answer to:

1. The datestamp is inserted by the provider.  Thus it could be a lie;  
this is the Internet, remember.  You, the consumer, either trust the  
publisher or you don't.  If you don't, you will ignore the datestamp  
and check the content.  If you do, you will believe the datestamp.   
Thus, "modified" buys you nothing.

2. There's endless room for argument as to what constitutes an update:  
change in the stylesheet for background colors, change from a unicode  
combined char to single + combining diacritic, change in paragraph 27  
of an article that doesn't show up in a summaries-only feed, change  
from UTF-8 to UTF-16 encoding, there were more examples too, some of  
them scary-subtle.

3. Several publishers on the list asserted that they needed the right  
to make trivial spelling-correction-level changes without having a  
zillion literal-minded feed-reading clients re-fetch the material, and  
that they would simply refuse to update an atom:modified date if they  
didn't feel like it.

Objectively, the upstream information provider controls the datestamps.  
  If you can think of a way to write a syndication format that will  
function across the Internet and reliably force providers to provide  
accurate "modified" indicators, there are a lot of people who would  
like to hear about it.

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 12:27:48 +0100

On 21 May 2005, at 2:41 am, Robert Sayre wrote:

> OK. The chairs' latest text reads:
>
> " If multiple atom:entry elements with the same atom:id value appear
> in an Atom Feed document, they describe the same entry and Atom
> Processors MUST treat them as such."
>
> Where does the bad behavior come in, and what can we do to  
> discourage it?

This line:
"Their atom:updated timestamps SHOULD be different"

What are the allowable exceptions here? If I wanted to store two  
versions with the same id and updated (say from two different  
sources, or which non-siginificanr differences, is that allowable.  
What should a client that implements "the typical behavior ... to  
display only the entry with the latest atom:updated timestamp" do?

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 16:19:48 +1000

On 21/5/05 10:48 AM, "Tim Bray" <[email-masked]> wrote:

> I don't see why, if you wanted that kind of archive, you couldn't use
> atom:updated for every little change in the archived version but
> atom:updated only for the ones you cared about in the published
> version.  In which case the archived version would be a superset of the
> published version.  I see nothing wrong with that. -Tim
> 

but how would the publisher signal the particular instances in that archive
which are 'significant' while others are not?

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 16:29:39 +1000

On 21/5/05 1:26 PM, "Roger B." <[email-masked]> wrote:

>>> change from a unicode combined char to single + combining
>>> diacritic,
>> 
>> No.
>> 
>>> change in paragraph 27 of an article that doesn't show up in a
>>> summaries-only feed,
>> 
>> No.
> 
> Dave: In my case, and seemingly in the case of most of the tools
> surveyed, both of those would get a "yes". I suspect that in many
> cases, simply clicking "edit" on an entry and then immediately
> clicking "save" will cycle the modified date forward, even if zero
> changes were made.

I concur -- most tools probably will update on any edit/save cycle. Some
tools won't, simply because they disable the "Save" command unless the edit
workspace has been dirtied. This is observable practice with lots of desktop
apps, but since it's a pain to implement in web apps I doubt we'll see it
there anytime soon.

On the point of changing a unicode combined char: I thing the Yes/No depends
on how the change occurred ... was it an load/edit/save cycle by a user, or
was it due to a software upgrade that affected how content is stored or
serialised?

e.

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 08:09:40 +0100

Saturday, May 21, 2005, 2:04:57 AM, I wrote:

> [reposted without so many typos and grammatical errors - reply to either]

I just noticed some irony in my attempt to repost that mail about
atom:modified, with the intention to disclaim that any "significant
changes" had been made, thereby saving any readers that had already
read and understood the long post from rereading it. Note that the
Atom mailing list archive retains both copies, ordered by the Date
header.

It is a bit borderline in this case, the original post was hard to
understand. But, if these had been atom entries rather than mailing
list posts, this is the sort of scenario where an archive Feed
Document needs to contain both revisions of an entry - in order - even
when the publisher doesn't advertise that the update was significant
by reving atom:updated.

-- 
Dave

---

From: Anne van Kesteren <[email-masked]>
Date: Sat, 21 May 2005 09:44:39 +0200

David Powell wrote:
> I detect that a lot of opposition to atom:modified comes from the fact
> that it is a REQUIRED element and that many of the publishers actually
> putting it in the feed and paying for the bandwidth don't intend using
> it frequently?
> 
> Would it help if we said that if the atom:modified element is absent,
> its value MAY be taken from the atom:updated element? (or to put it
> another way: atom:modified MAY be omitted if its value is equivalent
> to the value of atom:updated).

I think this will result in people misusing the field. Either giving 
atom:updated the last modified time or giving it the last significant 
modification time and simply omitting atom:modified because that is 
extra work.

If it is introduced in some optional fashion it should not relate to 
another date construct I think.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 07:53:59 +0100

> clicking "save" will cycle the modified date forward, even if zero

That is ok by PaceDateModified2. The "no" in my response was to the
question "Is this an update wrt the rules of atom:modiifed?"

PaceDateModified2 doesn't have the clause that PaceDateModifed has:
"Publishers SHOULD NOT change the value of atom:modified when no
changes in the entry have occurred", because of situations like this,
where this clause would be difficult to avoid and unenforceable.

It is preferable if publishers don't change atom:modified and/or other
elements in a feed document unnecessarily for caching reasons amongst
others, but cases like the ones above are likely to be infrequent and
harmless.

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 16:01:58 +1000

> Thus, "modified" buys you nothing.

I don't believe trust is a matter of "you do or you don't". I trust some
people to do some things, but don't trust them on other matters. The more
subjective something is, the less I might trust someone. The more
objective/automated, the easier it is to trust.

Will there be bad actors that will subjectively fiddle with atom:modified?
There are always bad actors... however, if they betray their skullduggery
nature by fiddling with something as objective as atom:modified why then
would I even begin to trust what they say in atom:content?

> from UTF-8 to UTF-16 encoding, there were more examples too, some of

I still say we need to define/clarify the difference between an "entry" and
atom:entry. That might help.

> that they would simply refuse to update an atom:modified date if they

The spec is also silent on whether a publisher must produce a new
serialisation of <atom:entry> every time there is a change in the back-end
resources. The spec does imply that if you do, then atom:modified would be
updated ... but if a tree falls on a mime in the

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 01:46:22 -0400

Graham wrote:
> What if someone (either the publisher or someone downstream)
> wants to store a history of every revision in an archive 
> feed?
To this, Tim Bray answered:
> I don't see why, if you wanted that kind of archive, you couldn't
> use atom:updated for every little change in the archived version
> but atom:updated only for the ones you cared about in the published
> version.  In which case the archived version would be a superset
> of the published version.  I see nothing wrong with that. -Tim

	Of course, the objections to Tim's position are obvious:
	1. The case of "someone downstream" was ignored in the answer. Tim
only addresses the issue of what the publisher might do. 
	2. Given Tim's "solution" to the problem, downstream readers would
be incapable of maintaining an accurate archive since only the publisher's
unpublished archive would have atom:updated values that change on each
modification.
	3. The "archive" that Tim describes would not actually be a useful
archive for many purposes since it would not be an accurate description of
the sequence of entries written to the feed. For instance, such an archive
would not satisfy legal rules for logging data in financial applications
since such an archive could not be used to determine the value of the
atom:updated value in entries that had actually been published.

	This whole argument is silly. Atom:modified is needed. It should be
provided. Nobody has given a decent argument against it. If you insist on
objecting to it then let the darn thing be optional -- but instead of trying
to impose your personal vision on the process, just let the rest of us get
on with doing the work we need to do in the way we know we have to do it.

	bob wyman

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 09:21:38 +0100

> I think this will result in people misusing the field.

It is hard to predict, but:

> Either giving atom:updated the last modified time

I think that these publishers will implement atom:updated
incorrectly regardless of whether atom:modified is defined, and
whether it is optional or not.

If atom:modified isn't defined at all, then this would be quite a
significant risk.

> or giving it the last significant modification time and simply
> omitting atom:modified because that is extra work.

Yes, this sounds like a risk. We could add a warning about what the
consequences might be: "The modified date MAY be used by processors to
select the latest revision of an entry. If multiple revisions of an
entry exist with the same atom:modified value, then processors MAY
select any available revision as the latest."

This would act as a good replacement for the contentious paragraph
about atom:updated that was dropped from PaceAllowDuplicateIDs.

> another date construct I think.

I support atom:modified whether it is syntactically mandatory, or
whether its value is implied if absent. As an alternative, I'm also
open to suggestions of a sequential revision id element, but I prefer
atom:modified.

-- 
Dave

---

From: "Roger B." <[email-masked]>
Date: Fri, 20 May 2005 22:26:13 -0500

--
Roger Benningfield

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 02:29:04 +0100

On 21 May 2005, at 2:15 am, Robert Sayre wrote:

>
> On 5/20/05, Graham <[email-masked]> wrote:
>
>> Say I'm aggregating feeds into a search results feed, and I get the
>> same entry twice (with the same atom:id and atom:updated), from
>> different sources. Would it be acceptable to me to adjust the
>> atom:updated by one second and put both in the results, to show the
>> end user the entry was available from two places?
>>
>
> I think you are conflating timestamps and version identifiers.

Just to be clear then, my example was meant to be of the sort of bad  
behavior PaceDuplicateIds encourages, not of something I'd want to  
do. It's the Pace that'd doing the conflating.

Graham

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 02:06:40 +0100

On 21 May 2005, at 1:48 am, Tim Bray wrote:

> version.  In which case the archived version would be a superset of  
> the published version.  I see nothing wrong with that. -Tim

That's exactly my problem. You're having to hack the dates to make it  
work. Would you encourage hacking in other ways?

If that's the intention, then I guess it's OK, but it certainly isn't  
elegant.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 21:15:31 -0400

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 02:04:57 +0100

As I was the last person to mention atom:modified, I'll refer to my
proposal as an example in this reply.

> Thus, "modified" buys you nothing.

The rationale for PaceDateModified2 was to enable multiple revisions
of entries to exist in the same Atom Feed Document. This usage doesn't
require trust relationships to be set up.

Cross-feed duplicate detection is a useful feature that requires a web
of trust to work reliably. Atom doesn't provide this natively, but
future companion specifications could provide a framework, just as
DomainKeys and other specifications are trying to do for SMTP.
Hopefully Atom deployments will be a bit more agile than SMTP, so this
wouldn't be such a slow process.

> 2. There's endless room for argument as to what constitutes an update:

The text of PaceDateModified2 is looser than most of the previous
proposals that were made, it is actually rather similar to the
mandatory atom:modified element in Atom 0.3. It is updated when
information in the entry (not the physical atom:entry element), which
is reflected in the document is changed.

Given that definition, I think that whether atom:modified needs to be
updated can reasonably answered:

> change in the stylesheet for background colors

No:  On the web you don't update the Last-Modified date for a web page
when a linked style-sheet has changed, nor would you update
atom:modified when documents linked to an Atom entry change. It is
implicit in any specifications which uses URIs to reference related
documents, that the representations are subject to change over time.
HTTP's extensive cache-control mechanisms deal with this.

No.

> change from UTF-8 to UTF-16 encoding

No.

No.

> that they would simply refuse to update an atom:modified date if they  

Re-fetch?  If they know that the atom:modified date has changed, then
they already have the entry don't they?

Do you mean that they want to discourage clients from re-fetching
linked images etc? HTTP cache control mechanisms are the way to do
this.  Most aggregators defer image retrieval to a browser widget, so
whether the document has changed or not will have no effect on whether
the linked documents are refetched for these implementations.

The Atom police wouldn't be able to stop people from ignoring the
specification and faking atom:modified to a fixed value, but the
effect for the subscriber would be similar to if a server operator
faked Last-Modified to a fixed value in HTTP.

The wide deployment of Atom 0.3 suggests that support for
atom:modified wouldn't be an unsurmountable burden for
implementations, but anyway, there is another alternative:

I proposed PaceDateModified2 to address the issue that feeds
containing multiple revisions of an entry would not be able to
distinguish which revision is the latest.  (Remember the entries are
unordered).

Some sort of atom:revision-count element would work too. Its value
could even be defaulted to 0 in its absence for minimal
intrusiveness.

I think that atom:modified is a better option though, because it has
uses beyond revision sorting within a document, and it is probably
easiest for implementations to implement given the widespread support
for a similar element shown in BlogToolDateSurvey.

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 May 2005 17:48:09 -0700

On May 20, 2005, at 5:07 PM, Graham wrote:

> Tim, can I ask about your thinking regarding the use of atom:updated 
> in PaceDuplicateIDs. What if someone (either the publisher or someone 
> downstream) wants to store a history of every revision in an archive 
> feed? atom:updates forces one to choose only one version per 
> "significant" change. The mechanism it affords (being able to 
> automatically display the newest version) is vital, but it doesn't 
> seem like the best way to do it.

---

From: Graham <[email-masked]>
Date: Sat, 21 May 2005 01:07:01 +0100

Graham

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 01:33:28 +0100

Cross-feed duplicate detection is a useful feature that requries a web

> 2. There's endless room for argument as to what constitutes an update:

The text of PaceDateModified2 is looser from most of the previous
proposals that were made, it is actually rather similar to the
mandatory atom:modified element in Atom 0.3. It is updated when
changes to information in the entry (not the physical atom:entry
element), that are reflected in the document are changed.

HTTP's extensive cache-control mechansisms deal with this.

No.

No.

No.

this.  Most aggregators defer image retreival to a browser widgit, so

Some sort of atom:revision-count element would work too. Its value
could even be defaulted to 0 in it's absense for minimal
intrusiveness.

-- 
Dave

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 18:37:43 +1000

> to the value of atom:updated).

I'm not opposed to the idea, but I will note that early on the WG really
disliked the idea of establishing precedence/default/fall-back rules for
dates.

e.

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 08:32:58 +0100

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 10:14:09 -0400

> provided. Nobody has given a decent argument against it.

I was deeply -1 and continue to be. Every single problem you're
talking about with atom:updated will simply be transferred to
atom:modified.

Timestamps are not version identifiers.
We can't standardize versioning.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 10:28:26 -0400

> "Their atom:updated timestamps SHOULD be different"

Ah. I misread their orders, thinking I was only to include the first
sentence. You're 100% right. Note that this does not mean I'm in favor
of atom:modified. Versioning problems aren't solved by timestamps.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 10:51:59 -0400

> I detect that a lot of opposition to atom:modified comes from the fact

A lot of the opposition comes from the fact the WG found it useless,
months ago. Allowing multiple atom:ids in a feed doesn't change that.

You want to sit here and talk about atom:modified for another month?
For an optional element that would be trivial to add as an extension?
I will sit here and argue it again, but I will probably  just pull
pages from the archives where we talked about this months ago.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 01:17:52 +1000

> We can't standardize versioning.

atom:modified more than hits the 80:20 mark, especially if we ignore the
edge cases of bad actors (which no proposal stands much chance against).

e.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 11:28:17 -0400

> edge cases of bad actors (which no proposal stands much chance against).

Oh, really? What are you applying that cliche to? What problem does it
solve? Maybe a concrete example would help.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Sat, 21 May 2005 20:31:55 +0100

> of atom:modified. Versioning problems aren't solved by timestamps.

Whoa!  I misread that too. (I mentioned the "contentious atom:updated
paragraph" that had been removed in an earlier mail - I didn't realize
that it was still in)

Just to be clear, is this the text that will be included in the next
draft? :

> If multiple atom:entry elements with the same atom:id value appear in
> an Atom Feed document, they describe the same entry and software MUST
> treat them as such.
> 
> Their atom:updated timestamps SHOULD be different, and processing
> software SHOULD regard entries with duplicate atom:id and atom:updated
> values as evidence of an error in the feed generation. If an Atom Feed
> Document contains multiple entries with the same atom:id, software MAY
> choose to display all of them or some subset of them. One typical
> behavior would be to display only the entry with the latest
> atom:updated timestamp.

This is much worse than I thought. That second paragraph is bad on so
many levels....

-- 
Dave

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 17:45:36 -0400

Robert Sayre wrote:
>Versioning problems aren't solved by timestamps.
	I don't understand why this "version" issue keeps coming up. It
should be apparent to everyone that there is NO relationship between
timestamp and version. Timestamps have only two functions:
	1. Different timestamps indicate different instances of an entry.
	2. Timestamps allow assumptions concerning temporal ORDER or
sequence to made

	It is totally reasonable for me to develop a "V1.0" followed by a
"V2.0" which is then followed by a "V1.1" -- if I have a reasonably rich
versioning scheme. If I then order-by-version, I would have the ordered set
"V1.0," "V1.1," "V2.0". However, if I order-by-time, I have the ordered set
"V1.0," V2.0," "V1.1". 
	I believe that atom:modified is intended only to permit
order-by-time. Certainly, that is all that is needed to address the vast
majority of use cases for which atom:modified has been declared useful.
Atom:modified is intended to allow processors to compare two non-identical
instances of a single entry and determine the order in which they should be
considered to have been created. Atom:modified allows us to say "This entry
is considered to have been created after that entry." Atom:modified does not
permit us to make any statements concerning "versions" or "variants."
	It is possible that some confusion is being introduced here since
one may notice that if a very simple, single-line-of-descent versioning
scheme is used, the time-ordered sequence of instances will be identical to
a version-ordered set of instances. However, this is merely an anecdotal
observation that applies to only one of many possible classes of versioning
policy. There is no general correlation between temporal order and version
order that applies across all versioning policies. Any correlation between
temporal-order and version-order should generally be considered coincidental
and not interesting.
	Knowledge of temporal order is extremely useful information that can
be usefully exploited by Atom Processors to deliver a number of capabilities
demanded by a variety of users. However, the current definition of Atom
(since it doesn't support atom:modified) does not permit general temporal
ordering of entries even when they are all published in a single feed. At
best, the current definition only allows us to temporally order sets of
entries that have the same atom:updated value. However, we have no means of
determining sequence or temporal ordering of the elements of a set whose
members share the same atom:updated value. This inability to order elements
of such sets is a significant weakness in Atom in that it introduces
ambiguity.
	Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values. This
has nothing to do with versioning.

	bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 17:49:23 -0400

> has nothing to do with versioning.

What does atom:id have to do with temporal ordering?

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 08:17:33 +1000

> What does atom:id have to do with temporal ordering?

It is used to select the members of the set which is to be temporally
ordered. It's not used in the ordering itself, of course.

In other words - if we have a set of entries, all with the same atom:id,
then atom:modified can be used to temporally order them. This is
particularly pertinent to those subsets which are defined by the entries
having the same atom:updated values.

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 18:24:30 -0400

> What does atom:id have to do with temporal ordering?
	Absolutely nothing.
	Atom:id is used to identify sets of entry instances which, according
to the Atom specification, should be considered "the same entry". Sets
composed of instances of "the same entry" can then be divided into subsets
that share a common atom:updated value. After such a division into subsets,
some of the subsets may contain multiple elements which cannot be temporally
ordered given the current Atom spec draft. atom:modified provides a means to
temporally order the elements of sets which contain multiple elements that
share common atom:id and atom:updated values.
	I believe this was communicated when I wrote:

"Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values."

	bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 18:28:36 -0400

> members of sets that share the same atom:id and atom:updated values."

No, that's not what you communicated. How can I temporally order atom
entries with different IDs but the same atom:updated value? atom:id
and atom:modified are completely unrelated.

I don't know what the problem is, but the answer is atom:modified!

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 18:51:40 -0400

> I don't know what the problem is, but the answer is atom:modified!

	Robert, it is clear that your disdain for the current discussions
has driven you to the point where you are no longer even reading the posts
to which you respond. This is not productive.
	I have said *nothing* about the temporal ordering of "atom entries
with different IDs". I have only written about the problem of providing
temporal ordering of atom entries that "share the same atom:id and
atom:updated values." 
	I repeat (with a few added words to make it even more clear):

"Atom should support atom:modified to permit the temporal-ordering of
 members of sets whose members share the same atom:id and atom:updated
 values."

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 18:57:46 -0400

>  members of sets whose members share the same atom:id and atom:updated

So, it's about disambiguating versions of an entry, right?

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 19:15:52 -0400

> So, it's about disambiguating versions of an entry, right?
	No. It has nothing to do with "versions" or even "variants." I have
explained that on numerous occasions. The denial of relevance to the issue
of "version" is even in the title of this thread. Read: "atom:modified
indicates temporal ORDER not version..." Clearly, you either aren't reading
what you're responding to or you simply don't understand what is written.

	Robert, it is YOU who keeps bringing "version" into this discussion
-- not I. Clearly, you are not acquainted with the manner in which the word
"version" is used in our industry. Only this could explain why you persist
in using the word in the colloquial sense popular to those not schooled in
computer science and software engineering. May I suggest that you read some
basic software engineering texts that discuss how our industry understands
the term "version"? Something that talks about "code management" or
"configuration management" might work well for you. There are many very
accessible basic introductory texts available that you might be able to
understand if you apply yourself and read carefully. If you need any help in
understanding what is written in the books, please feel free to send me a
mail asking for help deciphering the more difficult parts...

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 19:27:06 -0400

On 5/21/05, Bob Wyman <[email-masked]> wrote:
> what you're responding to or you simply don't understand what is written

Temporal order of what? They are all the same entry, so what is it you
are temporally ordering? Why is this a new problem that only arises
when we allow multiple IDs in the same feed?

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Sun, 22 May 2005 02:17:30 +0200

On 22 May 2005, at 01:27, Robert Sayre wrote:
> are temporally ordering?

You are temporally ordering states of the entry.
Or if you think of the id as the resource for which the <entry>...</ 
entry>
text is a representation, then you are ordering the representations
sequentially/temporally.

> Why is this a new problem that only arises

I don't think this is a problem that only arises when we allow  
multiple ids in the
same feed.

Henry

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 20:23:10 -0400

Robert Sayre wrote:
> Temporal order of what? They are all the same entry, so what is it
> you are temporally ordering?
	We are discussing the temporal ordering of multiple non-identical
*instances* of a single Atom entry. It is common in the realm of software
engineering to deal with this concept of "instances." Things are often
considered to be simultaneously "different" and "the same". (I am who I am
today -- as I was when I was a child, nonetheless, I am very different today
than I was when I was a child. The instance of me today differs from the
instance of me that you might have come across many years ago.) But, perhaps
this concept is too abstract for some readers...

> Why is this a new problem that only arises when we allow multiple
> IDs in the same feed?
	I have been pointing out these issues since long before the issue of
"multiple IDs" (multiple instances) recently regained attention. The issue
exists even without duplicate id support but is particularly critical once
we support multiple instances of an entry in a single feed document.
	In the absence of "duplicate id" support, a reader can infer the
temporal order of entries by simply noticing the order in which the entry
instances were read from a feed document. (If duplicate ids are prohibited,
then if you have read two entry instances which share a common atom:id, they
must have been read from different instances of feeds and at different
times. Thus, you can infer in some cases that the temporal ordering of the
entry instances approximates the temporal ordering of the read operations
which retrieved the entry instances. ) 
	However, if you permit multiple instances of an entry in a single
feed document then it is possible that you will read multiple entries whose
temporal order cannot be inferred. (Note: Order of appearance in a feed does
not imply any inter-entry order and thus cannot be used to infer or discover
the temporal ordering of entries.)
	Thus, this issue *is* related to the "multiple ID" issue in that the
problem is exacerbated by permitting multiple instances of a single entry in
a single feed document. Whether or not it is relevant in other contexts is
largely irrelevant since it appears that addressing the issue in one context
will resolve it in other contexts as well.

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 20:27:04 -0400

On 5/21/05, Bob Wyman <[email-masked]> wrote:
> engineering to deal with this concept of "instances." 
>
> Things are often

I'm unconvinced. Have a giant -1.

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Sun, 22 May 2005 02:38:42 +0200

> I'm unconvinced. Have a giant -1.

How can you be unconvinced about something so fundamentally basic
to human thought? People change over time. When you clip your nails
your body is not the same as it was before, yet as far as the law is
concerned, you are the same person who went to whatever school you  
went to.
Change over time exists. For something to be able to change there has to
be something that is the thing that changes.

Really you can't get more basic than this. If you are left to argument
over this, I would suggest moving your discussion over to a philosophy
forum.

Henry

---

From: Tim Bray <[email-masked]>
Date: Sat, 21 May 2005 18:05:59 -0700

On May 20, 2005, at 6:06 PM, Graham wrote:

>> but atom:updated only for the ones you cared about in the  
>> published version.  In which case the archived version would be a  
>> superset of the published version.  I see nothing wrong with that.  
>> -Tim
>>
>
> That's exactly my problem. You're having to hack the dates to make  
> it work. Would you encourage hacking in other ways?

I'm not hacking at all.  In this scenario, for archiving purposes I  
consider all changes no matter how small significant, and thus  
preserve them all with different values of atom:updated.  For  
publication to the web, I have a different criterion as to what is  
significant.  I fail to see any problem in the archive being a  
superset of the feed.

> end user the entry was available from two places?

There may be a reason to trust one of the sources more than the  
other.  If so, choose that.  If not, apply the a policy such as  
discarding any entries whose ID you've seen unless the atom:updated  
is later than what you've seen so far. -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 21 May 2005 18:08:57 -0700

On May 20, 2005, at 8:26 PM, Roger B. wrote:

> surveyed, both of those would get a "yes".

Existence proof, if any were needed, that the notion that there is  
such a thing as an "objective change" is just silly.  Anybody who has  
worked with the deployment of more than two professional publishing  
systems knows full well that there is very little agreement on what  
constitutes a change.  Attempting to specify a protocol element to  
capture a mythological quantity strikes me as bad design. -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 21 May 2005 19:36:05 -0700

Summary: David Powell fails to materially address any of the three  
fatal flaws I pointed out in the notion of atom:modified.  I remain  
firmly at -1.

> wouldn't be such a slow process.

This entirely fails to address my basic point: that if you trust the  
publisher's judgment as to what's significant, then atom:updated is  
good enough.  If you don't atom:modified doesn't help.

> updated can reasonably answered:

I entirely disagree, based on years of experience in publishing  
applications, and there was disagreement with your judgment on these  
cases posted to the list within 3 hours.  The notion that any two  
organizations can agree on what objectively constitutes an update is  
unsupported by the evidence.

> they already have the entry don't they?

No.  Lots of entries are summary-only, not full-content.  In my case,  
I do some of both, and in the long entries that are summary-only, I  
regularly make minor changes to the trailing part of long entries and  
decline to refresh the feed or the atom:updated date, specifically  
because I do not went each of the ten thousand or so newsreaders who  
fetch my feed to go and re-get the entry because I fixed a typo in  
paragraph 11.

Q.E.D. -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 23:01:16 -0400

Tim Bray wrote:
> for archiving purposes I consider all changes no matter how small
> significant, and thus preserve them all with different values of
> atom:updated.  For publication to the web, I have a different
> criterion as to what is significant.  I fail to see any problem
> in the archive being a superset of the feed.
	The problem is that such an archive would not accurately reflect
what you actually published to the web. Thus, for many applications, you
would also have to keep a distinct log of what you published. Using your
archive you wouldn't be able to meet various legal requirements that apply
to a number of businesses which require that you be able to show what you
published.
	The problems get worse if you include signatures in your entries.
Using your archiving method, the signatures on your archived entries would
be different for the signatures on the entries you published.
	The "archive" method you describe does not produce a "superset" of
what you published; it is a different set of data from that which you
published. This is not necessary.

	bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 May 2005 23:10:11 -0400

Tim Bray wrote:
> I regularly make minor changes to the trailing part of long
> entries and decline to refresh the feed or the atom:updated date, 
> specifically because I do not went each of the ten thousand or
> so newsreaders who fetch my feed to go and re-get the entry
> because I fixed a typo in paragraph 11.
	It seems like you are concerned that people who see a change in your
feed will re-fetch the HTML? If this is your concern, then do as you do now
and don't refresh the feed unless you have a change that warrants an update
to atom:updated. This is totally up to you and support for atom:modified
wouldn't change that. There is no requirement that your feed change whenever
you modify your posts. Thus, there is nothing that stops you from pursuing
this policy. You are essentially arguing that the standard should force
everyone to have a blog that works in the manner that your blog works. That
is not reasonable. To argue that the standard should make it possible for
you to do things the way you want is quite reasonable. But, you should give
to others the same consideration you apparently demand from them.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Sat, 21 May 2005 20:32:18 -0700

On May 21, 2005, at 8:10 PM, Bob Wyman wrote:

> to atom:updated.

No.  As a matter of policy, my feed contains the most recent 20  
posts.  However, if one of those posts is a long post and only the  
summary is provided, when I make a change, I make a conscious  
decision whether it's sufficient that I want newsreaders to re-fetch  
it, and if so I change the datestamp, otherwise not.

> This is totally up to you and support for atom:modified
> wouldn't change that.

Yes, atom:modified would require that I update the date, and have the  
entry fetched another ten thousand times, even if I made a change  
that struck me as trivial.  Since I'm a good citizen about specs, I  
would do this wasteful thing.  Others would just ignore it. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Sat, 21 May 2005 20:51:05 -0400

> over this, I would suggest moving your discussion over to a philosophy

Gee, Henry, maybe you should draw us a UML diagram to explain all this. 

Robert Sayre

---

From: Phil Ringnalda <[email-masked]>
Date: Sat, 21 May 2005 21:08:24 -0700

Tim Bray wrote:
> entry fetched another ten thousand times, even if I made a change  that 
> struck me as trivial.  Since I'm a good citizen about specs, I  would do 
> this wasteful thing.  Others would just ignore it. -Tim

No, not at all. With only atom:updated, you either say "everyone must 
re-read this" or you don't. With both atom:updated and atom:modified, 
you can either say that, or you can say "only obsessives running 
BrayWatcher need to notice that two letters of this have changed." At 
least to me, that was the whole point: I am going to replace my current 
RCS-based "show me every trivial edit" system with an Atom-based one, 
while still being able to tell aggregators that they don't need to 
bother their users when I just fix a typo. The only question is if I do 
it with atom:modified, which will let me also do it for my 
Blogger-produced feeds, where I don't control the output, and do it so 
other people can use it too, or if I do it with phil:modified, and it 
only works for me, and only with some of the tools I use to publish.

Phil Ringnalda

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 22 May 2005 00:53:53 -0400

Tim Bray wrote:
> As a matter of policy, my feed contains the most recent 20  
	Finally, your true motivations appear. It is now clear that you're
not talking about Atom itself. Rather, you are trying to regulate the
behavior of Atom Processors who will be using Atom feeds somewhat like
"ping" feeds that tell them which entries to fetch. Your concerns are easily
addressed by providing text in the specification that makes clear what you
want.

I therefore propose the following text:

To the discussion of both atom:updated and atom:modified add:
"[Non-Normative: In order to preserve network bandwidth and reduce the load
on hosts of resources linked to Atom feeds or entries, Atom Processors which
fetch the contents of alternate links are advised that they should not
re-fetch such contents unless atom:updated changes.]"

To the discussion of atom:modified add this normative text:
"The value of atom:modified MUST only be changed when some other element
(including atom:updated) of the same Atom entry has changed. Changes which
are limited to resources linked to the Atom Entry MUST NOT trigger changes
to atom:modified."

> Since I'm a good citizen about specs, I would do this wasteful thing.
	If the spec were written as I have proposed above, then you -- as a
"good citizen" -- would never re-fetch the alternate linked resources unless
atom:updated changed.

	The difference here is that my comments have been solely focused on
the contents of the Atom feed -- which is all that PubSub is concerned with.
Nonetheless, the proposed texts should resolve your issues while allowing
PubSub to do its job.

	bob wyman

---

From: Graham <[email-masked]>
Date: Sun, 22 May 2005 06:03:41 +0100

> significant.  I fail to see any problem in the archive being a  

It's not a superset, or an archive. The details of the atom:updated  
value that each  revision was published with have been lost.

>> Say I'm aggregating feeds into a search results feed, and I get  
>> the same entry twice (with the same atom:id and atom:updated),  
>> from different sources. Would it be acceptable to me to adjust the  
>> atom:updated by one second and put both in the results, to show  
>> the end user the entry was available from two places?
>

Yes, but why? Why not allow both versions to travel downstream?

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sun, 22 May 2005 14:39:00 +1000

On 22/5/05 1:10 PM, "Bob Wyman" <[email-masked]> wrote:

> There is no requirement that your feed change whenever
> you modify your posts.

+1

---

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 13:21:16 +0100

> capture a mythological quantity strikes me as bad design. -Tim

Did you get my response to Rogers' mail? I said that atom:modified
"does not need" to be updated in these cases. However, if a publishing
client has made the effort to post the changes to a server, and a
server has made an effort to commit these changes to the database,
then as with the case of a publisher committing a null change, it is
not expected that the implementation makes a judgement call over
whether there was really an update. atom:modified is much simpler than
that.

PaceDateModified2 deliberately doesn't prohibit this, nor does this
prevent the proposal from fulfilling its goal to provide a temporal
ordering for entry instances.

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Sun, 22 May 2005 14:02:19 +0100

> fatal flaws I pointed out in the notion of atom:modified.  I remain  

Tim, thanks for taking the time to make specific points discuss this
in detail, despite your opposition to it. This is productive route to
progressing the debate towards the rejection or approval of these
proposals.

> good enough.  If you don't atom:modified doesn't help.

I've addressed this in "Re: updated and modified yet again". The value
of atom:updated is specified as author's opinion. I trust that it is
your opinion, but I'd like the option of forming my own.

For users reading your feed, your opinion is likely to be accurate;
for archivers reading your feed, it is not.  It depends on the purpose
on the purpose of the processor - Here is an example:

Your publishing provider provides a feature which allows you to
download an archive of the entries that you posted. Would you expect
the archive to contain all of the instances of entries that you posted
and were visible for t seconds/days/weeks/years on the Internet - or
would you expect the archive to discard the instances with the same
atom:updated value?

My expectation of an archive, is that it would record everything that
had been posted and had been live on the Internet at any point in
time.

> unsupported by the evidence.

Roger's cases? Like I said, either option would have satisfied
PaceDateModified2, and either option would have satisfied its goal as
a temporal ordering of entry instances.

> fetch my feed to go and re-get the entry because I fixed a typo in  

Ok - sorry I didn't interpret your argument accurately.  You are
concerned with aggregators accessing alt links every time an
atom:modified date is updated.

atom:modified, I'll say it again, provides a temporal ordering of
entry instances.

Software that uses it to flash "THIS ENTRY HAS CHANGED" messages at
users, is not serving the user well, as the atom:updated value
provides a more accurate means of doing this, for this set of
processors - ie humans reading a feed.

Software could adopt an equally paranoid behaviour by hashing the
entry contents and using changes in it to communicate that an entry
has changed. Neither method would serve the user well.

-- 
Dave

---

From: "Roger B." <[email-masked]>
Date: Mon, 23 May 2005 00:18:53 -0500

> ordering for entry instances.

Dave: I'm pretty much +0 on PDM2, as I've mentioned previously. Your
modifications to the concept address my "this will break stuff"
concerns with the original formulation, so I'm okay with however it
works out.

But I have a question, and I'm asking you specifically because you
seem to be approaching your argument in a reasonable tone and fashion.
My apologies if I'm pestering.

Near as I can tell, folks have modification dates. In my case, that is
a date that is updated every time the user clicks "save". In Tim's
case, that is a date that he chooses. In other apps, that may be a
date that matches when a new comment was added to a blog entry.
Nothing in the spec is going to change these realities.

And none of these approaches are *wrong*, or invalid. We each get to
define "change" in our own apps, so we can approach atom:modified's
MUST clause as we see fit. For all practical purposes, it doesn't
matter whether folks use atom:updated or atom:modified. You're going
to get the same date.

With that in mind, what are the actual benefits of atom:modified over
atom:updated? The end result will always be identical, unless I'm
missing a crucial, well-hidden point.

Please note that it has not escaped me that this cuts both ways. Why
fight for atom:updated over atom:modified when it is beyond the scope
of the Atom spec to define the nature of change in the universe? Hey,
if Tim doesn't consider a typo a real modification, then it just
isn't. Period. It's his writing, his app, and he defines the rules and
the terms.

The more I look at this, the more I see people fighting over phantoms.

--
Roger Benningfield

---

From: Eric Scheid <[email-masked]>
Date: Mon, 23 May 2005 15:47:10 +1000

> missing a crucial, well-hidden point.

atom:updated is predicated on a new feature yet to be built into common
blogging tools -- the concept of specifying if this change is a
"significant" change. Most tools just proffer something approximating
atom:modified, some tools provide a user-editable date which could be used
as a round about way of signifying a "significant" change.

theoretically, we're hoping that people won't just smush atom:modified types
of values into atom:updated (since it is a required element), preferring to
leave atom:updated with it's initial value (effectively atom:published). If
common practice is to dump an automated "last modified" value into
atom:updated, then the intent and purpose of atom:updated will have been
defeated by all that pollution. Which would be sad.

e.

---

From: Henry Story <[email-masked]>
Date: Mon, 23 May 2005 14:32:43 +0200

I just found an excellent article on the subject of identity:

http://plato.stanford.edu/entries/identity/

It is heavy reading. But it does give an excellent overview of the  
subject.
I can't say that I managed in a couple of hours to fully digest all  
the information
in there.

Henry

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 24 May 2005 00:05:50 +0200

>are limited to resources linked to the Atom Entry MUST NOT trigger changes
If I already voted, please consider I've changed my mind to the following:

+0.8 to atom:modified, +1 if it is optional

+1 to the above quoted text if atom:modified is accepted

-- 
Thomas Broyer

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 24 May 2005 00:14:45 +0200

> +1 to the above quoted text if atom:modified is accepted
Remove the "+1 if it is optional", I'm rather confused about optionality 
here...

Sorry for Tim and Paul who are trying to count the points :-[

-- 
Thomas Broyer

---

From: David Powell <[email-masked]>
Date: Tue, 24 May 2005 00:17:30 +0100

Monday, May 23, 2005, 6:18:53 AM, Roger B wrote:

> I'm asking you specifically because you seem to be approaching your
> argument in a reasonable tone and fashion. My apologies if I'm
> pestering.

No apologies required, I welcome any useful criticism.

> matter whether folks use atom:updated or atom:modified.

> You're going to get the same date.

You may get the same date in some cases, but not all.  explained below...

> missing a crucial, well-hidden point.

When a publisher updates an existing entry, the value that they put in
atom:updated combines three parameters:

a) The last modified date of the entry (ie: the value that would go
     into atom:modified if it existed)
     
b) The atom:updated value of the previous instance.

c) Whether the publisher's opinion is that the change is significant.
     (some publishing systems may not allow the publisher to express
     this opinion - in that case, this parameter will be hard-coded)

The publisher chooses whether the new atom:updated value should be the
current modification date, or the previous atom:updated value based on
whether, in their opinion the change is significant.

If a publisher wants to change an entry, and wants to
indicate that in their opinion the change was not significant, the
current draft allows them to do this by publishing a new version of
the entry with the same value of atom:updated as the previous version.

The problem is, for a set of instances of an entry (ie where the entry
was modified over time) atom:updated is the only way for a publisher
to indicate the order of those instances.  So these instances become
second-class, in the sense that the publisher is prevented from
communicating this information.

Given multiple instances of an entry, one original, and one that has
been corrected, it is impossible to tell which is which, so any
processor has a 50% or greater chance of displaying the wrong version.

Fortunately, under typical circumstances, a Feed Document doesn't
contain more than one instance of the same entry, so you can work out
the order of instances from two separate polls based on when you
polled the feed. But under other circumstances this is important.

An example - Atom is supposed to support archiving according to the
charter, but it isn't possible to archive a feed, unless you don't
mind either a) the order of instances of entries that appeared in your
feed being lost (so that it is impossible for a reader to tell which
of two instances is the later one that incorporates corrections);
or b) the archiver stripping out older instances before putting them
in the archive - but this means that you only have a partial archive
of what was published in your feed.

Note that without atom:modified an archiver could only support b) if
it was tightly coupled with the publishing process because the current
draft of Atom is incapable of representing the modified dates of entry
instances necessary for the archiver to strip out the older instances.

(see <http://www.imc.org/atom-syntax/mail-archive/msg15549.html> - for
more discussion of this example)

PubSub is another example of a system where this is a problem - it's
probably best to read what Bob Wyman says about that though.

The recommendation made by PaceAllowDuplicateIDs to use atom:updated
to select the latest instance of an entry, is a completely
inappropriate use of atom:updated given its semantics, but
unfortunately it is the only course of action unless atom:modified (or
something similar) is introduced.

> isn't. Period. It's his writing, his app, and he defines the rules and

It has been suggested that atom:modified is being proposed because the
processor mistrusts the publisher, or the publisher's opinion, or
because the processor doesn't find the opinion significant. This
couldn't be further from the truth.

Without atom:modified, the feature of atom:updated that allows a
publisher to express their opinion on significance, is a false
promise.  If publishers don't update atom:updated, the entry becomes
second-class. In effect, in your example, if Tim wants to use Atom in
certain ways, he won't get the option to express whether his
modification is significant or not because the meaning of atom:updated
in the spec is distorted by the implications of PaceAllowDuplicateIDs.

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Tue, 24 May 2005 08:18:28 +0200

My thought currently is that atom:updated by being the sole date in  
atom is in
fact what people are thinking of as atom:modified.

It is just specified very flexibly and constrained not by language  
but by how it will
be used. The game of publishing entries will push people to be  
reasonably precise about
what they consider to be a change:
     - if they don't, their entries may be lost
     - creating a new time stamp is so easy, there is no reason not  
to change the
       time stamp by default

So I am in fact -1 on atom:modified.

It would be silly to have 2 dates in atom,  we would then just have  
more confusion and
corner cases. The more precise date would inevitably be considered  
the real one, and the
other one ignored in any case. Adding a more precise definition of  
what constitutes a
change is beyond the ability of this working group given the way it  
has to come to an
agreement.