> PaceClarifyDateUpdated
+1.
atom:updated is not atom:modified or dc:modified, and we need to guard
against that if the special semantics of atom:updated are not be smothered
under a flood of atom:modified pollution.
-1. Doesn't make sense or add value to the document.
Robert Sayre
--On February 6, 2005 1:07:42 PM +0200 Henri Sivonen <[EMAIL PROTECTED]> 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
Bill de hÓra wrote:
Tim Bray wrote:
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."
Strong agreement and as I'm not constrained by being a chair, I'll go
furt
Tim Bray wrote:
On Feb 6, 2005, at 3:16 AM, Henry Story wrote:
Thinking about it, I would be in favor of clarifying it to be
"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 make
On Feb 6, 2005, at 3:16 AM, Henry Story wrote:
Thinking about it, I would be in favor of clarifying it to be
"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
ver
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 modification dates in my current RSS feed are based on the HTTP
Last-Mod
From what has been said recently previous versions of RSS had
no versioning mechanism. It was therefore not possible for software
to automate the difference tracking behavior. Hence your problem is
partly related to the limitations in the previous formats.
Since Atom does in fact have a versioning
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
On Feb 6, 2005, at 11:56, Roger B. 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?
Henri: As a practical matter?
Yes. Also as a spec expectation--that is, how often is
> 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?
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
On Feb 6, 2005, at 01:48, Graham wrote:
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 res
On 6/2/05 10:48 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> Therefore, other modifications SHOULD NOT result in a changed
> atom:updated value.
+1
e.
Graham wrote:
#pragma section-numbers off
== Abstract ==
Clarify when not to update atom:updated
+1
cheers
Bill
#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
15 matches
Mail list logo
