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
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.
Near as I can tell, folks have modification
Sunday, May 22, 2005, 2:08:57 AM, Tim Bray 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
Sunday, May 22, 2005, 3:36:05 AM, Tim Bray wrote:
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.
Tim, thanks for taking the time to make specific points discuss this
in detail, despite
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: I'm pretty much +0 on PDM2, as I've mentioned previously. Your
modifications to the concept address my this will break
On 23/5/05 3:18 PM, Roger B. [EMAIL PROTECTED] wrote:
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.
atom:updated is predicated on a new feature yet to be built into
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
On 21/5/05 9:40 AM, Tim Bray [EMAIL PROTECTED] wrote:
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
On 21/5/05 1:26 PM, Roger B. [EMAIL PROTECTED] 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
On 21/5/05 10:48 AM, Tim Bray [EMAIL PROTECTED] 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
Saturday, May 21, 2005, 4:26:13 AM, Roger B. 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
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
This whole argument is silly. Atom:modified is needed. It should be
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
On 5/21/05, Graham [EMAIL PROTECTED] wrote:
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
On 22/5/05 12:14 AM, Robert Sayre [EMAIL PROTECTED] wrote:
This whole argument is silly. Atom:modified is needed. It should be
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
On 5/21/05, Eric Scheid [EMAIL PROTECTED] wrote:
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).
Oh, really? What are you applying that cliche to? What problem does it
solve? Maybe a concrete
Saturday, May 21, 2005, 3:28:26 PM, Robert Sayre wrote:
This line:
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
On May 20, 2005, at 6:06 PM, Graham 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
On May 20, 2005, at 8:26 PM, Roger B. 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
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.
On May 20, 2005, at 6:04 PM, David Powell wrote:
1. The datestamp is inserted by the provider. Thus it could be a
lie;
this is the
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
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
On May 21, 2005, at 8:10 PM, Bob Wyman wrote:
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.
Tim Bray wrote:
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
No,
Tim Bray wrote:
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
On 22/5/05 1:10 PM, Bob Wyman [EMAIL PROTECTED] wrote:
There is no requirement that your feed change whenever
you modify your posts.
+1
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.
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.
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
[reposted without so many typos and grammatical errors - reply to either]
As I was the last person to mention atom:modified, I'll refer to my
proposal as an example in this reply.
1. The datestamp is inserted by the provider. Thus it could be a lie;
this is the Internet, remember. You, the
On 21 May 2005, at 2:15 am, Robert Sayre wrote:
On 5/20/05, Graham [EMAIL PROTECTED] 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
31 matches
Mail list logo
