Subject: atom:updated vs entry inheritance?

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 01:24:34 +1000

Gah! What is the true atom:updated for the following entry?

<feed>
    <updated>2005-05-12T02:22:59+0000</updated>
    <author>...</author>
    <copyright>...</copyright>
    <entry>
        <updated>2005-05-11T01:11:59+0000</updated>
        <id>...</id>
        <summary>...</summary>
        <title>...</title>
    </entry>
</feed>

e.

---

From: "Roger B." <[email-masked]>
Date: Thu, 12 May 2005 11:04:10 -0500

> Gah! What is the true atom:updated for the following entry?

Eric: The entry-level version, IMO.

--
Roger Benningfield

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 12 May 2005 17:13:31 +0100

>         <updated>2005-05-11T01:11:59+0000</updated>

feed/entry/updated

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 02:49:03 +1000

> Eric: The entry-level version, IMO.

What if an atom processor had previously seen that entry with that
atom:updated ... should it do anything with it? Should it update it's local
store in any way?

What if the /atom:feed/atom:author element had been changed (and the
publisher thought that was significant)?

e.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 12 May 2005 20:20:09 +0200

>         <updated>2005-05-11T01:11:59+0000</updated>

Well, I don't see any problem here, as the enclosing document (the feed) 
is said to have been updated later than the enclosed one (the entry).
A feed's atom:updated may be later than its latest entry's atom:updated, 
because you might have changed its title, subtitle, icon, links, etc.

It would have been an error, IMO, if the feed's atom:updated had been 
earlier than its latest entry's atom:updated. However, the spec don't 
state anything like that. Should I make a Pace?

-- 
Thomas Broyer

---

From: Antone Roundy <[email-masked]>
Date: Thu, 12 May 2005 12:39:47 -0600

On Thursday, May 12, 2005, at 12:20  PM, Thomas Broyer wrote:
> Well, I don't see any problem here, as the enclosing document (the 
> feed) is said to have been updated later than the enclosed one (the 
> entry).
> A feed's atom:updated may be later than its latest entry's 
> atom:updated, because you might have changed its title, subtitle, 
> icon, links, etc.

Eric, was your point that the entry might be inheriting data from the 
feed which was updated after the entry was updated, and therefore, the 
entry might be though of as having been updated after it's atom:updated 
timestamp?  Other than that, I don't see any problem--the entry was 
updated when at the time indicated by it's atom:updated element.

But back to my question--if for example, the feed/author was updated at 
the time indicated by feed/updated:

1) If the author of the entry was NOT intended to be changed, the 
publisher should have put the old author into the entry.
2) If the author of the entry WAS intended to be changed, and the 
publisher considers this significant to the entry, then the publisher 
should have updated feed/entry/updated.

Because neither of those was done, from the XML shown above, we must 
assume that whatever change was made to the feed at the time in 
feed/updated did NOT affect the entry in a way that the publisher 
considered significant enough to update feed/entry/updated.  Another 
one for the implementors guide?

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 05:40:23 +1000

On 13/5/05 4:39 AM, "Antone Roundy" <[email-masked]> wrote:

> entry might be thought of as having been updated after it's atom:updated

Yes. Which has implications in implementations. Consider an implementation
that stores entries in a local database, but doesn't bother doing a record
update if it later sees the same entry where /entry/updated hasn't changed.

> publisher should have put the old author into the entry.

true. not a problem.

> should have updated feed/entry/updated.

I agree. You can see how easy it would be to not do that though. It could
also be argued that the publisher has signalled the significance by updating
/feed/updated, and thus effectively /feed/entry/. The ambiguity bothers me.

> one for the implementors guide?

Yes, another for the implementors guide.

e.

---

From: Henry Story <[email-masked]>
Date: Thu, 12 May 2005 23:12:28 +0200

> publisher thought that was significant)?

Just to recapitulate: we have 2 feed documents with successive atom  
updated
values, and with the same entry (same id) with the same time stamp  
but some values
that are not identical. Does the newer feed document trump the older  
one?

Does this not all depend whether you are an optimist or a pessimist?
     The optimist will think that the future is always an improvement  
over the past, and
so think that the new feed he has received will be giving a  
correction on the old state
of the entry.
     The pessimist will think that the future is worse than the  
present, and think that
the newer version of the feed documents must contain a mistaken entry.

Henry

---

From: Eric Scheid <[email-masked]>
Date: Fri, 13 May 2005 07:22:58 +1000

On 13/5/05 7:12 AM, "Henry Story" <[email-masked]> wrote:

> Just to recapitulate: we have 2 feed documents with successive atom  updated
> values, and with the same entry (same id) with the same time stamp  but some
> values that are not identical. Does the newer feed document trump the older
> one?

I assume what you mean by "values" includes the explicit elements of the
<entry> *plus* the implicit elements inherited from the <feed>. Right?

It follows then that /feed/updated applies *only* to the feed meta-data, and
possibly also the feed entries as a collection of opaque blobs. That is, the
contents of the entries don't inherit any 'significant change' semantic from
/feed/updated.

Best practice then would be to update /feed/entry/updated if an inherited
/feed/element is updated 'significantly'.

I'm happy with that.

e.

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 12 May 2005 23:51:23 +0100

> /feed/updated, and thus effectively /feed/entry/. The ambiguity bothers me.

"thus effectively", does not follow. That's not warranted unless we say 
it is. There's no ambiguity, at best there's an optical illusion 
provided by looking at an XML structure with programming language scope 
rules in mind. If you're still concerned people are going to get the 
wrong impression, I'd probably support spec text making such scoping 
matters explicit - I imagine this would result in a subsection since 
dates are not the only issue I think.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Fri, 13 May 2005 09:10:00 +0200

> <entry> *plus* the implicit elements inherited from the <feed>. Right?

Oh. I understand your puzzle now (reading this list a little fast at  
times)
I had forgotten about inheritance. The simplest solution is just to  
remove
these inheritance rules of course.

Henry