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 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 you do, you will believe the datestamp.
Thus, "modified" buys you nothing.
The rationale for PaceDateModified2 was to enable multiple revisions
of entries to exist in the same Atom Feed Document. This usage doesn't
require trust relationships to be set up.
Cross-feed duplicate detection is a useful feature that requires a web
of trust to work reliably. Atom doesn't provide this natively, but
future companion specifications could provide a framework, just as
DomainKeys and other specifications are trying to do for SMTP.
Hopefully Atom deployments will be a bit more agile than SMTP, so this
wouldn't be such a slow process.
This entirely fails to address my basic point: that if you trust the
publisher's judgment as to what's significant, then atom:updated is
good enough. If you don't atom:modified doesn't help.
2. There's endless room for argument as to what constitutes an
update:
The text of PaceDateModified2 is looser than most of the previous
proposals that were made, it is actually rather similar to the
mandatory atom:modified element in Atom 0.3. It is updated when
information in the entry (not the physical atom:entry element), which
is reflected in the document is changed.
Given that definition, I think that whether atom:modified needs to be
updated can reasonably answered:
I entirely disagree, based on years of experience in publishing
applications, and there was disagreement with your judgment on these
cases posted to the list within 3 hours. The notion that any two
organizations can agree on what objectively constitutes an update is
unsupported by the evidence.
3. Several publishers on the list asserted that they needed the right
to make trivial spelling-correction-level changes without having a
zillion literal-minded feed-reading clients re-fetch the material,
and
that they would simply refuse to update an atom:modified date if they
didn't feel like it.
Re-fetch? If they know that the atom:modified date has changed, then
they already have the entry don't they?
No. Lots of entries are summary-only, not full-content. In my case,
I do some of both, and in the long entries that are summary-only, 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
paragraph 11.
Q.E.D. -Tim
