Subject: updated and modified yet again

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

Bob Wyman in particular and others in general have argued eloquently  
for the utility of atom:modified in managing feeds and distinguishing  
between temporally-varying instances of the same thing.

I agree with the usefulness of doing what Bob and others want to do,  
and that they need to disambiguate successive versions of entries  
based on date.  I don't think this is controversial or surprising.

I do not agree in the slightest that atom:modified is any more useful  
than atom:updated for these purposes.  The only distinction between  
modified and updated is that there might be changes, not considered  
significant by the publisher, which occur between atom:updated- 
timestamped versions.

I'll repeat that.  The only difference is that there might be changes  
not considered significant by the publisher.

So the only reason why atom:modified can ever be more useful is if  
you disagree with the publisher's opinion as to what is significant.   
If you disagree to this extent, what reason is there to believe that  
you will agree with the publisher as to what constitutes a change?   
Or that you will trust the publisher to actually insert a changed  
version in the feed upon a change that is not considered  
significant?  Or that you will trust the publisher not to just lie?

And if you don't trust the publisher on these things, then why would  
you believe atom:modified anyhow?

I just don't believe that the difference between updated and  
published is operationally useful in the slightest.

In future argument, please don't argue any more that it's important  
to maintain successive versions or to track temporal differences.  I  
believe all that.  Instead, please explain why you expect to disagree  
with publishers' opinions as to what is significant and, in the case  
where you disagree, you feel you would trust atom:modified.

Absent such explanation, I am totally -1 on atom:modified.  -Tim

---

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

> you disagree with the publisher's opinion as to what is significant.
	If this "framing" of the issue was valid, then there would be no
reason to support atom:modified. However, the framing is NOT valid.
	It is not necessary for an Atom processor to "disagree with the
publisher's opinion" in order to be interested in what atom:modified would
provide.
	If I have two non-identical entries, each with the same atom:id and
the same atom:updated, I need an algorithm that can be used to determine
which of the two entry instances should be presented to a consumer who only
wishes to see one entry. It would be desirable if the decision could be made
in a non-random fashion. If asked, I think 99% of consumers will say that
they would prefer if I present them with which ever of the two entries was
"most recently" created. The problem is that Atom does not permit me to
satisfy this user request. Without atom:modified, I can't determine which of
the two entry instances was "most recently" created. Not being able to
satisfy a consumer request is, in my business, considered a bad thing. 
	Without atom:modified, the best I can do is tell the user:
"Sometimes I'll give you the latest entry, but at other times, I'll just
randomly pick one of several instances. If you object, it is simply because
you are either ignorant or because you disagree with the publisher. It's not
my problem..." I don't think I'll win any customer service awards with an
attitude like that...

> what reason is there to believe that you will agree with the publisher
> as to what constitutes a change?
	I have no intention of disagreeing with the publisher. Atom:updated
clearly identifies when the item has, in the opinion of the publisher,
changed "significantly." However, by allowing multiple entry instances that
share a common atom:updated value Atom explicitly provides for communicating
"non-significant" changes and the WG apparently expects publishers to put
entries which have been modified in non-significant ways into their feeds.
Customers may be perfectly willing to accept the publisher's statements
concerning the significance of changes. Nonetheless, they will still
typically wish to see which ever instance was most recently published. In
order to meet consumer requirements, we need to be able to determine which
one of multiple instances of an entry is the "most recent." I am not looking
to disagree with the publisher -- I only want to know the order in which
changes, significant or not, have been made so that I can satisfy the
readers' desires.

> version in the feed upon a change that is not considered significant?
	If it ain't in the feed, who cares? The only thing that matters when
discussing Atom is what's in an Atom feed or entry document.  Any concerns
for "trusting" that the content of an Atom feed actually reflect resources
that are not defined by Atom is simply outside the scope of this Working
Group.

> Or that you will trust the publisher not to just lie?
	Publishers can lie in any element. The fact that they might lie
about atom:modified is neither shocking nor relevant.

> you believe atom:modified anyhow?
	As said before, I fully intend to "trust" publishers and fully
expect that if people produce entries that don't have the correct data in
any element that those entries will get treated in potentially unexpected
ways. I expect to conform to the specification. Others who wish to have
their data processed in a predictable way should also conform. Those who
don't conform -- screw 'em.

	bob wyman

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 22 May 2005 06:22:10 +0200

* Tim Bray <[email-masked]> [2005-05-22 04:50]:
> I do not agree in the slightest that atom:modified is any more
> useful than atom:updated for these purposes. The only
> distinction between modified and updated is that there might be
> changes, not considered significant by the publisher, which
> occur between atom:updated-timestamped versions.

I don’t think this is the only purpose. I can see a case mainly
for archival. Another use case might be RecentChanges newsfeeds
for wikis, where there generally is a concept of minor and major
edits that are nonetheless all considered to have significance,
just of different levels.

I can certainly see these use cases to an extension element and I
don’t think it would hurt much to do so.

I wonder, though, if it would hurt anything to introduce an
OPTIONAL atom:modified element for those cases where the
publisher wants it, and that it only means something when
provided? In particular, publishers would not be required to
provide it and would certainly not be required to change it for
“every change to an entry.” It would be nice for use cases such
as wikis if clients could be relied upon to understand such an
element when present.

Regards,
-- 
Aristotle

---

From: Tim Bray <[email-masked]>
Date: Sat, 21 May 2005 21:29:16 -0700

New flash!  Bob and I agree!

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

> the two entry instances was "most recently" created.

Bob is right.

IF      you find an two entries with the same atom:id and the same  
atom:updated
AND IF  you are inclined to believe that the difference will be  
interesting
AND IF  you believe that date-stamping is a useful way to resolve  
this issue
THEN    atom:modified gives you a decision procedure.

However, I believe that this kind of collision is an anomalous rare  
case, and I believe that most times it happens they're going to be  
actual duplicates that are exactly the same, and I believe that if  
there are differences, if the publisher is to be trusted the  
differences are not going to be interesting, and I believe that if  
they are interesting, there's a chance you're looking at the  
potential DOS attack that Bob highlighted, which case atom:modified  
is not much (any?) help.

Plus, atom:modified is actively harmful because it encourages people  
to believe (falsely) that there is consensus on what an "update"  
means (remember the thousands of messages we invested chewing this  
over because certain WG members from Norway had a violently  
incompatible mental image-entirely correct for their app-of what a  
"change" was?), and also to believe (falsely) that they don't have to  
worry about whether to trust a feed provider.

-1 on atom:modified.

My opinion on this is not weakening. -Tim

---

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

> Absent such explanation, I am totally -1 on atom:modified.  -Tim

Let's assume first, that you aren't deliberately putting false data in
your own feed:

When you post an entry to a feed it is a subjective decision whether
you change the atom:updated element based on your opinion of whether
the change is significant. If I want to keep an archive of your feed,
then I trust that atom:updated 100% reflects your opinion on
significance. But it doesn't mean that I share that opinion. I may
have a more discerning criteria, so I want to represent a copy of all
instances. It isn't a question of trust, in this case I trust that you
have used a truthful value of atom:updated.

A modified date is not subjective. When you post an entry to a feed,
this communicates to the subscriber the modified date, nothing more.
An archiver can use this to preserve the temporal ordering of entry
instances.

(Perhaps a better use case, would be to replace "I" in that
explanation with "The archiving feature of your posting software or
provider")

On the other hand, if you are deliberately putting false data in
your own feed, Atom does not attempt to deal with this situation,
whether atom:modified is included or not.

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Mon, 23 May 2005 11:35:01 +0200

On 22 May 2005, at 06:29, Tim Bray wrote:
>
> News flash!  Bob and I agree!

I have been following this discussion and am finding I am also  
agreeing with
Tim, Bob and Aristotle P. The points are subtle.

This made me wonder if the points are not playing themselves out a  
different
level. Perhaps the problem is that we are not clear about the  
difference between
semantics and what is being said.

At the level of semantics an entry as identified by its id has a  
number of
dated representations. These representations can be grouped in  
different ways
according to different identity criteria. One very precise such  
identity criteria
would be string identity. Two representations are identical if they  
are character
by character identical. Another identity criteria, lets call it  
update identity,
says that two such representations are equivalent if they have the  
same atom:updated
time stamp. This is a very vague identity criterion, which leaves it  
up to the
interaction between users and consumers to set constraints on the  
criterion. The
user has to face the fact that consumers may drop some of his changes  
(conceived of
as changes under the criterion of string identity) if he does not  
change the date.

So let us think of this from the point of view of the three players  
in this game: the
original publisher, the final consumer, and the intermediary.

The original publisher
----------------------

When the publisher is the same person as the person defining the  
identity criteria,
then it makes sense that he should not publish two entries in a feed  
that are identical
according to his own criteria. This can not be conceived to be a  
restriction on him.

The final consumer
------------------

The final consumer may have different identity criteria to the  
publisher of the
feed, but since he is not the one to publish the feed there is not  
much for him
to do. He cannot force the original publisher to be more precise,  
because that
would be to ask the person who is publishing to see a distinction  
where he sees
none. And this does not even take into account that other consumers  
may disagree
with him anyhow.

The aggregator
--------------

The problematic case comes from those aggregating feeds. And I think  
here I can identify
two different problems:

     a- The aggregator may say he has different identity criteria  
from the publisher. If he
has then one can simply answer: your business is to be transparent,  
not to place yourself
in between your user and his public.

     b- The aggregator wants to be completely transparent. But has a  
problem because he is
not sure who to trust, and different people are making different  
claims about the same
thing (the id). In everyday life there is a well known method for  
doing this honestly: we
quote the source of who said what. If Smith says that the red car is  
his and John says that
the car is his, I don't need to say that the car belongs to Smith and  
to John, I can just say
"Smith says that 'the car is his' and John says that 'the car is  
his'". I just need to
quote what others have said.
    If this is the problem faced by Bob then I don't think  
atom:modified is going to help.
That would be being precise in the wrong place. What would have  
helped was perhaps the solution proposed by Roy Fielding a few months  
ago, namely that a feed should be able to contain a feed. Bob's pub  
sub service would then be just able to quote what others (feeds) have  
said. It would
then have been correct to hold the position currently held that no  
feed should *directly*
contain an entry with the same atom:updated value. It would allow  
that a feed could contain two
feeds each with different entries containing the same id and the same  
atom:updated time stamp.
It would then be up to the consumer to decide which one it trusts.

Henry Story