Subject: PaceClarifyDateUpdated

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 23:48:51 +0000

#pragma section-numbers off

== Abstract ==

Clarify when not to update atom:updated

== Status ==

Open

== Rationale ==

The second sentence ("not all modifications...") is a bit vague and 
conceivably contradicts the first (which implies "only some", second 
implies "most"). NB This is not an attempt to change the meaning.

== Proposal ==

Change second sentence of:

    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 producer considers significant.  Therefore, not all modifications
    necessarily result in a changed atom:updated value.

To:

    Therefore, other modifications SHOULD NOT result in a changed 
atom:updated value.

== Impacts ==

None.

== Notes ==

----

CategoryProposals

---

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

> Clarify when not to update atom:updated

+1

cheers
Bill

---

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

+1

e.

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 6 Feb 2005 09:15:10 +0200

>    Therefore, other modifications SHOULD NOT result in a changed 

What do you propose one should do when the current system to which Atom 
output is to be added do not record such updates but only records the 
date when the bytes changed?

The modification dates in my current RSS feed are based on the HTTP 
Last-Modified value returned by Apache.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: "Roger B." <[email-masked]>
Date: Sun, 6 Feb 2005 03:56:45 -0600

> date when the bytes changed?

Henri: As a practical matter? If that's what you have, that's what you use. 

But a lot of it comes down to knowing your audience and your
priorities. If something on your box routinely tweaks your
Last-Modified dates without making material changes, and you've got a
lot of readers using aggregators that flag updated entries, you'll
probably annoy some folks. You get to decide if that matters to you...
if it does, turn off whatever is changing Last-Modified, or kludge
together something to insert static dates into atom:updated.

--
Roger Benningfield
JournURL

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 6 Feb 2005 13:07:42 +0200

On Feb 6, 2005, at 11:56, Roger B. wrote:

> Henri: As a practical matter?

Yes. Also as a spec expectation--that is, how often is the "SHOULD NOT" 
expected to be violated. Will the SHOULD NOT be violated so often that 
it dilutes the meaning of all SHOULD NOTs?

> If that's what you have, that's what you use.

Right. The alternatives would be making significant changes to the 
system or not producing an Atom feed.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henry Story <[email-masked]>
Date: Sun, 6 Feb 2005 12:16:10 +0100

Thinking about it, I would be in favor of clarifying it to be
"any change should result in a date update". Clients can
do simple diffs and work out themselves if the changes warrant
a new date. Presumably clients that see that the only change has been
to the white space layout may decide that this is not important enough
to notify their user.

Henry

---

From: Graham <[email-masked]>
Date: Sun, 6 Feb 2005 12:59:29 +0000

On 6 Feb 2005, at 7:15 am, Henri Sivonen wrote:

> What do you propose one should do when the current system to which 
> Atom output is to be added do not record such updates but only records 
> the date when the bytes changed?
>

The current wording of date:updated has exactly the same issue. It's 
not relevant to this pace. You do have several options

a) Use Last-Modified, asserting all changes are "significant"
b) Use the same date as atom:published, asserting no changes are 
"significant"
c) Use Last-Modified, since it's SHOULD NOT and not MUST NOT, so if 
you've consider the interop issues it's fine.

(b) is my favourite because it's by far the most compatible.

Graham

---

From: Tim Bray <[email-masked]>
Date: Sun, 06 Feb 2005 06:46:25 -0800

On Feb 6, 2005, at 3:16 AM, Henry Story wrote:

> "any change should result in a date update".

If you will go back and review the correspondence, you will discover a 
lot of argument, the upshot of which was, different publishers have 
very different semantics for what they consider an update.  I had a 
posting months and months ago that enumerated a bunch of corner cases 
(e.g., stylesheet update) that made the whole notion of "any change" 
rather problematic.  There were many who, like you, liked the notion of 
"objective change" that always changed the date.  The reason that we 
have "updated" with the current language is it reflects the reality 
that the *only* kind of change that can be cleanly defined is "The 
publisher thinks it changed."

I'm not going to, under my co-chair's hat, heading for the airport to 
go on vacation, rule this discussion out of order, but it's 
borderline... -Tim

---

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

>> "any change should result in a date update".

No, atom:update is subjective. How UIs support that subjectivity is best 
left to innovation. I like Graham's wording as it makes me think UI 
designers will need to give 'save != update' proper consideration.

> lot of argument, the upshot of which was, different publishers have very 
> different semantics for what they consider an update.  I had a posting 
> months and months ago that enumerated a bunch of corner cases (e.g., 
> stylesheet update) that made the whole notion of "any change" rather 
> problematic.  There were many who, like you, liked the notion of 
> have "updated" with the current language is it reflects the reality that 
> the *only* kind of change that can be cleanly defined is "The publisher 
> thinks it changed."

Strong agreement and as I'm not constrained by being a chair, I'll go 
further than Tim - using this pace to reopen objective updating is out 
of order.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sun, 06 Feb 2005 12:37:45 -0500

Bill de hÓra wrote:
> 
> Tim Bray wrote:
> 
>> The reason that 
>> we have "updated" with the current language is it reflects the reality 

It's certainly out of order (imho), but the Pace doesn't make sense 
anyway. One of the nice things about RFC2119 is that it provides a 
couple different ways to say everything. Let's try RECOMMENDED instead 
of SHOULD:

---
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 
producer considers significant.  Therefore, it is NOT RECOMMENDED that 
other modifications result in a changed atom:updated value.
---

uh, yeah...

Robert Sayre

---

From: Walter Underwood <[email-masked]>
Date: Mon, 07 Feb 2005 09:00:53 -0800

--On February 6, 2005 1:07:42 PM +0200 Henri Sivonen <[email-masked]> wrote:
>
> Yes. Also as a spec expectation--that is, how often is the "SHOULD NOT" expected
> to be violated. Will the SHOULD NOT be violated so often that it dilutes the
> meaning of all SHOULD NOTs?

Roughly, a SHOULD or SHOULD NOT can be violated when the implementer 
understands and accepts the interoperability limitations they of that
decision.

So, the spec should (must?) explain what those are.

wunder
--
Walter Underwood
Principal Architect, Verity