Subject: Re: Propose partial consensus on dates

From: "Arve Bersvendsen" <[email-masked]>
Date: Wed, 21 Jul 2004 23:01:06 +0200

* Tim Bray

> 1. Each entry must have a "modified" which is an assertion from the 
> publisher as to when the resource was last changed.  This should be in 
> RFC3339 format.  Example: a travel journal, the entry for the 8th was 
> <atom:modified> on the 17th.

+1 on the assumption that this is a date generated by a tool, not a person.

> 2. Each entry may have a "display" date - you can think of it as part 
> of the title - which is the date primarily associated by the publisher 
> with the resource.  Example: the travel-journal entry for the 8th has 
> an <atom:display> of the 8th.  There remain outstanding problems of 
> both name and format on this one, see below; however, the date is 
> machine-processable, not free text.

See below.

> 3. Each entry may have a "created" date - the date on which it came to 
> be.  For example, the travel-journal entry for the 8th was 
> <atom:created> on the 11th.  RFC3339.

+1 on the assumption that this date is immutable and machine generated

> - what the right format is for "display"

If we can agree that "display" is a user-submitted, subjective date, my
suggestion is that it should simply be treated as a string for human - not
machine - consumption. Alternatively that this is made to be some construct
providing both, e.g.

<date>
  <created ... />
  <issued ... />
  <modified .../>
  <display>
    <utc>2004-12-31T23:59:59Z</utc>
    <string>New year's eve</string>
  </display>
</date>

> - are there any must-have missing dates (I wonder if "created" could be 
> defined in a way that would meet at least some of the needs around 
> "issued").

I don't think so. In publishing processes beyond the blog scope, "issued" has
a very specific meaning, very different from "created".

> - if you disagree that we have rough consensus as outlined, say so, 
> nobody's feelings will be hurt.

I (too?) believe that there is rough consensus on 'created' and 'modified',
given my previously mentioned assumptions.

The biggest issue with dates, however, seems to be 'issued', and that issue
is heavily bound to the notion of re-issuance and entry:id:

- My view is that if a major modification is made to an entry, it is no
longer the same entry, but a new entry, with a new entry:id.
- This new entry MUST contain explicit information about which entry it
"supersedes" [1]. 
- Hence: an issued date becomes immutable, and as "objective" as the
authoring tool makes it.

This view of issued, together with "display" solves the Samuel Pepys Use
Case, since the display date is then not bound to anything specific, except
the original author's perceptual timeline [2]. 

Further: 
- When the "issued" date is immutable, simplistic aggregators (without any
notion of "revisioning") will not suffer any data loss when reading from an
aggregator that supports "minor and major edits" [3]. An aggregator with
revision support, would pick up the minor edits anyway, so no data is "lost"
as such. These aggregators could, when reading from 'untrusted' sources
(sources with no known revisioning support) also apply additional heuristics
to determine the "size" of an edit, to determine if it should re-display the
entry
- For two aggregators that supporting revisioning, they now have a way to
positively recognize whether an edit is minor or major, making Atom more
usable in a b2b scenario.

The only "inconveniences" ever possible, are these:
- a revisioning aggregator that doesn't redisplay minor modifications, _and_
that lacks the notion of differencing. I presume it will still show the
modified entry when explicitly asked to redisplay.
- an aggregator without revisioning support, might view "re-issued" as new
entries (which they, from the author's point of view are, anyway) without
giving a notion that this entry supersedes a previous entry.

Turning on my "end-user"-glasses, these two inconveniences are, IMHO, far
outweighed by the advantages.

___
[1] "Supersedes" as a generic term - the exact semantics might as well be
borrowed from Dublin Core, for instance relation @isVersionOf

[2] I assume that Samuel Pepys diary was not 'formally issued' until it was
released in book-form. This way, my current proposal would allow all aspects
of the diary to be represented: When it was created within the publishing
system. When it was last modified (again within the publishing system), when
Samuel Pepys wrote it, and when it was first unleashed upon the public.

[3] What "minor" and "major" is, will always, sadly, be open to
interpretation, no matter _how_ we choose to word it.

-- 
Arve Bersvendsen

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 21 Jul 2004 15:00:41 -0700 (PDT)

--- Arve Bersvendsen <[email-masked]> wrote:
> machine - consumption. 

Strong disagreement here. The primarily need for this
date is to model pubDate in RSS which is a user
configurable field in most blogging tools but machine
readable. Creating a field that can be any garbage
text the user wants makes this field quite useless. 

> given my previously mentioned assumptions.

What is the consensus? My position is that 'created'
is unnecessary in general although somebody may find
use for it if they were using Atom as an archival
format. In the debate of modified vs. updated I'd
point out that few (if any blogging tools) today
support the functionality described by updated.
Specifically the ability for a user to specify that a
significantly edited article should somehow be
highlighted as rewritten which differs from tracking
if any modification such as fixed typos have occured
isn't something I've seen in any blog tool nor have I
heard anyone requesting this functionality before
until the Atom date debate began.  

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 22 Jul 2004 00:48:14 +0200

On Wed, 21 Jul 2004 15:00:41 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> In the debate of modified vs. updated I'd point out that few (if any
> blogging tools) today support the functionality described by updated.

What's funny is, however, that any «supersede» mechanism I and Arve have  
proposed is _already_ supported in _all_ aggregators. Okay, they don't do  
anything smart with the reference to the previous version of the entry,  
but they display it as a new entry. Just as they should.

> Specifically the ability for a user to specify that a significantly
> edited article should somehow be highlighted as rewritten which
> differs from tracking if any modification such as fixed typos have
> occured isn't something I've seen in any blog tool nor have I heard
> anyone requesting this functionality before until the Atom date debate
> began.

True, but it doesn't need to be like that either. It's a hypothetical use  
case. The advantages of re-issuing entries as new entries (with new ID's)  
instead of infinately updating the same entry still outweighs any  
drawbacks (which I think are itsy bitsy) with not supporting the supersede  
mechanism.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Robert Sayre <[email-masked]>
Date: Wed, 21 Jul 2004 19:42:24 -0400

> drawbacks (which I think are itsy bitsy) with not supporting the supersede

NewsML[0] uses an <update> content element rather than a timestamp. Reuters'
old school wire format does the same thing, I think.

<!ELEMENT Update (InsertBefore | InsertAfter | Replace | Delete )*>

Something like this is an option for us, how many times have you seen blog
entries that say things like "<b>Update:</b> I was wrong..."?

I like this because the changes are visible in the document structure. A
timestamp just encourages more frequent polling.

This feels like the right way to do it, IMHO. If it's too complex, let's
just push it out of core.

Robert Sayre

[0] 
http://www.newsml.org/IPTC/NewsML/1.2/specification/NewsML_1.2-spec-function
alspec_7.html#Struct

---

From: Eric Scheid <[email-masked]>
Date: Thu, 22 Jul 2004 10:18:14 +1000

regarding atom:modified and the like...

Are we only considering changes to the atom:content, or would changes in
other elements trigger a change in atom:modified? What if an entry gets some
extra name-spaced extensions larded in after the fact ... is that considered
a modification of the entry?

I suggest that it is. Tools can then rely on atom:modified as a signal to
dump and reload. Tools don't need to necessarily understand the extra
elements, or even do anything with them, but they should replace their
locally held data with the new data.

e.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 22 Jul 2004 10:37:47 +1000

> until the Atom date debate began.

It's common in wikis (but not the atom wiki, ironically)

There's even a mod-wiki extension for RSS which includes a field for
signifying major/minor update.

e.

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 22:41:12 -0400

On 21 Jul 2004, at 6:48 pm, Asbjørn Ulsberg wrote:

> What's funny is, however, that any «supersede» mechanism I and Arve 
> have proposed is _already_ supported in _all_ aggregators. Okay, they 
> don't do anything smart with the reference to the previous version of 
> the entry, but they display it as a new entry. Just as they should.

The wrongness of this suggestion is beyond words. The aggregator is not 
working "just as it should". The aggregator is being confused and 
manipulated by a second-rate hack. I read the specs, I see that <guid> 
never changes even when the entry does. I decide I want my aggregator 
to only display the latest version of each entry, and I write it to use 
<guid> that way. You disagree, you come up with a hack that will mean 
it shows two versions of the same entry (all good aggregators keep 
archives). Yes, your <supercedes> tag would clear up the mess, but to 
suggest that aggregators today will work "just at it should" is 
nonsense - it's being borked by the corrupt data you're deliberately 
sending it.
Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 21 Jul 2004 20:46:28 -0700 (PDT)

> nonsense - it's being borked by the corrupt data

+1 

I was about to make the same comment myself about how
RSS Bandit works. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 22 Jul 2004 09:39:32 +0200

On Wed, 21 Jul 2004 22:41:12 -0400, Graham <[email-masked]> wrote:

> manipulated by a second-rate hack.

You consider this method a «hack», although all institutions,  
organizations and companies in the world that has anything resembling a  
publishing process, does superseding as the only way to change (everything  
but small typographical erratas) the content of a document (both in analog  
and digital form). As I wrote in my entry[1] about this:

See W3C’s specifications, for instance. The HTML specification[2] exists  
in a pack of different versions, where each newer version supersedes an  
old one. The latest HTML 4.01 specification[3] is a supersede of the April  
24th 1998 version[4] which again is a supersede of another version of the  
April 24th 1998 version[5] which in turn is a supersede of the the  
November 7th 1997 version[6] and so on.

So, what W3C does, if I understand your comments correctly, is a  
«second-rate hack». Correct?

> I read the specs, I see that <guid> never changes even when the entry
> does.

The ID doesn't _change_, because the superseding entry is a new entry that  
relates to the old one. This isn't about changing ID's. This is about  
_not_ changig 'issued' to achieve almost the same result as a superseding  
mechanism gives you. This is about realising that a «major update» of an  
entry isn't really an update of that particular entry, but a brand new one.

____
[1] <url: http://www.virtuelvis.com/quark/archives/188.html>
[2] <url: http://www.w3.org/TR/html/>
[3] <url: http://www.w3.org/TR/1999/REC-html401-19991224/>
[4] <url: http://www.w3.org/TR/1999/PR-html40-19990824/>
[5] <url: http://www.w3.org/TR/1998/REC-html40-19980424/>
[6] <url: http://www.w3.org/TR/REC-html40-971218/>

---

From: Sam Ruby <[email-masked]>
Date: Thu, 22 Jul 2004 08:45:30 -0400

> «second-rate hack». Correct?

Many, many times I wish that Graham would refrain from using such 
emotionally charged language because many times I find myself agreeing 
with what he said, but not with the way in which he said it.

This is one of those times.

Between friends, playing chess, "do overs" may be permitted.

"Do overs" (taking back a move made in error) are not permitted in 
professional chess tournaments.

The W3C is professional.  They don't revise specifications in place. 
Instead, they issue new ones that supercede old ones.

If you wish to run your blog that way, that's fine.

Imposing that level of professionalism on all casual usages of blogs, 
however, is inappropriate.

Graham doesn't want to outlaw updating in place, he merely wants to be 
able to deal with it.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 22 Jul 2004 07:46:16 -0700 (PDT)

--- Asbj�rn_Ulsberg <[email-masked]> wrote:
> entry isn't really an update of that particular
> entry, but a brand new one

I love the ambiguity of this stuff. What the heck is a
major update? So you're saying that users will see the
same post twice in their aggregator but that's OK
because a 'major' update has been done but there is no
way to explain to users what exactly is meant by
'major update'. 

Hmmmm. Sounds very user unfriendly to me. 

=====

---

From: Antone Roundy <[email-masked]>
Date: Thu, 22 Jul 2004 09:56:28 -0600

> Hmmmm. Sounds very user unfriendly to me.

Let's apply this approach to some more elements:

* What the heck is a title?  Well, it's a few words to give people an 
idea of what appears in the content.  But are they the right words?  Or 
did the author chose them badly?  Is the title element user unfriendly 
because authors write bad titles?  Should we drop it from the format?  
Is there a way to explain to users exactly what should go in the title?

* What the heck is a summary?  Well, it's something longer than the 
title, but it serves a similar purpose--giving the reader a quick 
preview of what's in the content.  But if, as will probably not be 
uncommon, the author just puts the first paragraph of the content into 
the summary, is it a good summary?  Is it a summary at all?  If the 
content is well written, then it may very well be, but not all content 
is well written--some first paragraphs don't even come close to 
summarizing what follows them. Perhaps we should nuke the summary.

* While we're at it, lets nuke content, and just have links to content 
appearing elsewhere on the internet.  That way, we won't have to 
explain what to put in any of those troublesome elements, and no one 
will have to suffer from feed publishers' bad choices.

I'm sure the above sounds utterly absurd to you.  Understand that your 
assertions that publishers can't make intelligent decisions about 
whether an entry has changed enough to warrant them checking a box that 
says "this entry has changed significantly--make it appear in people's 
feed readers again" sound equally absurd to some of us.  Will some 
people make that decision badly?  Sure.  And some people will 
unsubscribe from their feeds because of it.  Just as they'll lose 
subscribers if they write bad headlines, summaries and content.  Will 
others make the decision judiciously?  Yes.  Will that add value to 
their feeds?  Yes.

---

From: Ken MacLeod <[email-masked]>
Date: 22 Jul 2004 11:15:11 -0500

"Arve Bersvendsen" <[email-masked]> writes:

> The biggest issue with dates, however, seems to be 'issued', and
> that issue is heavily bound to the notion of re-issuance and
> entry:id:
> 
> - My view is that if a major modification is made to an entry, it is
> no longer the same entry, but a new entry, with a new entry:id.
> - This new entry MUST contain explicit information about which entry
> it "supersedes" [1].
> This view of issued, together with "display" solves the Samuel Pepys
> Use Case, since the display date is then not bound to anything
> specific, except the original author's perceptual timeline [2].

For the sake of discussion, what happens if concensus is not to adopt
this view (model) in the core.  What would it look like for this model
(view) to be mapped into or layered over the Atom model?

In the [current] Atom model, the resource being identified is the one
that "has multiple versions".  It's not [currently] specified whether
atom:issued date is the "re-issued" of the most recent version or
"first issued" of the multiple versions.

We could relax the restriction that atom:entry/atom:id be unique by
saying that they *are* in fact the same entry, but different versions
(with the version identifier in an extension), and clients should use
the last-modified entry.  Clients can ignore missing versions because,
as in practice today, they don't need them as long as the
atom:entry/atom:id is the same as any previous version.

We could also specify that atom:issued is the date of the version, and
the "first issued" date can either be in an extensions or tracking
down the first published version of the "resource that has many
versions".

Would that work?

  -- Ken

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 22 Jul 2004 09:30:01 -0700 (PDT)

--- Antone Roundy <[email-masked]> wrote:
> I'm sure the above sounds utterly absurd to you. 

Nope they don't. Every feature added is added
complexity. Design is all about hitting the right
cost/benefit balance of complexity to features. I
think the distinction between summary and content is
unnecessary complexity but many seem to like it. Many
blog tools allow titles to be optional and I've met
users of such tools who'd rather not use titles.
However the benefit of such features is much more than
the added complexity of having these features in the
format that may either go unused by some or misused by
others. 

Having some date that is tied to an amorphous concept
like 'significant update' will be a usability problem
for aggregators. Any aggregator author with a decent
user base will tell you that one of the most
irritating problems for users are when duplicate items
show up in their aggregator.  This misfeature you are
proposing is actually enshrining this into the Atom
spec. 

=====

---

From: Graham <[email-masked]>
Date: Thu, 22 Jul 2004 12:32:33 -0400

On 22 Jul 2004, at 3:39 am, Asbjørn Ulsberg wrote:

> organizations and companies in the world that has anything resembling 
> a publishing process, does superseding as the only way to change 
> (everything but small typographical erratas) the content of a document 
> (both in analog and digital form).

It doesn't matter if the EU, the MFI and the Moonies organize their 
documents that way. RSS doesn't. Atom 0.3 doesn't. They don't have a 
<supercedes> element, and no aggregator supports one.

> This is about realising that a «major update» of an entry isn't really 
> an update of that particular entry, but a brand new one.

If you say so, Asjborn.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Thu, 22 Jul 2004 11:22:45 -0600

> format that may either go unused by some or misused by

Okay, there was some sense behind the arguments, but certainly not 
nearly enough to support nuking title and content--which is what I 
meant to say would be absurd.  (Less absurd for summary, but still, I 
think the benefit outweighs the cost).

> proposing is actually enshrining this into the Atom

To clarify my position, my comments were not meant to be taken entirely 
within the context of the thread--I'm not in favor of issuing major (or 
minor) changes to an entry as a new entry.  What I favor is enabling 
publishers to make a distinction between little adjustments and 
"significant updates".  I don't see it being too much of a headache for 
aggregator authors, because they can give the user an option to 
redisplay updated entries or not.  They can give their users even finer 
grained control by enabling them to redisplay only updates that the 
publisher considered "significant".  Enabling the user to override 
their global setting for particular feeds where the publisher thinks 
every change is major would be the icing on the cake in my view.

A question then to be sure that I understand your position.  In 
http://www.imc.org/atom-syntax/mail-archive/msg06958.html when you said 
+1 to:

 > Date 1: Updated
 >
 > This date is meant to be a machine generated
 > timestamp indicating when
 > the most recent substantive change has been made to
 > the entry.

were you supporting updated as defined by Sam (including the word 
"substantive") or were you intending to say +1 to an updated date when 
the last change of ANY kind was made (removing the word "substantive")?

One other question: if the modified date (whether limited to 
"substantive" changes or not) is not to be used in conjunction with 
redisplay of altered entries, would you have any use for it at all?

Antone

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 22 Jul 2004 10:25:47 -0700 (PDT)

> <supercedes> element, and no aggregator supports

No aggregator supports Atom 1.0 either so the fact
that something hasn't been supported in the past is no
argument that it can't be supported in the future. 

I'd rather debate the feature on its merits than
whether it has been supported by tools in the past or
not. 

By the way I dispute that the W3C supercedes
documents. A spec has two URIs, the URI that
identifies a version of a technology (e.g.
http://www.w3.org/TR/REC-xml) and one that identifies
the actual iteration of that document (e.g.
http://www.w3.org/TR/2004/REC-xml-20040204). If I only
go to the main URI for a W3C document then to me the
changes happened in place. In fact, this caused a
problem for SOAP when the W3C changed
http://www.w3.org/TR/soap/ to point to the SOAP 1.2
spec instead of the SOAP 1.1 spec since many people
use that URI to identify SOAP 1.1 since it was teh
only version that existed. The eventually backpedalled
and made the URI point to a landing page. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 22 Jul 2004 17:31:52 -0700 (PDT)

> A question then to be sure that I understand your
http://www.imc.org/atom-syntax/mail-archive/msg06958.html
> when you said 

I was saying +1 to having a single date field for
indicating the last time an item was changed. I doubt
aggregators or content producers will try to
differentiate between last-time-a-type-was-fixed and
last-time-a-major-revision-was-made when displaying
content to the user. 

In RSS Bandit, I don't prompt the user when it is
discovered that the content of an item is changed but
if I did I wouldn't differentiate between either date
since this distinction would seem arbitrary to users.
Because it would be since it would vary from feed to
feed and entry to entry. 

=====

---

From: Walter Underwood <[email-masked]>
Date: Thu, 22 Jul 2004 17:57:27 -0700

--On Thursday, July 22, 2004 8:45 AM -0400 Sam Ruby <[email-masked]> wrote:
> "Do overs" (taking back a move made in error) are not permitted
> in professional chess tournaments.
>
> [...]
>

I was thinking along the same lines. Different publications have
different policies for issuance and modification. This is normal
and reasonable.

Atom should specify a base semantic for these dates and let the
publications refine that.

The same holds for author, title, etc. All these things have
local policies.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:20:11 +0200

> Instead, they issue new ones that supercede old ones.

Yes. Just a note; W3C is not at all alone in performing this practice.

> however, is inappropriate.

We wouldn't. A supersede mechanism would be highly optional. It would  
probably best fit in an extension to the core. But if Atom wants to  
provide a way for publishers to separate minor from major modifications, I  
feel that the current practice in other (more professional) publishing  
areas should be adopted, instead of creating a new mechanism unique for  
Atom.

I (and the publishing industry) could probably live with an 'updated'  
element that signify major modifications. I think, however, that this  
should be plucked out of the core and put into an extension, and that the  
extension should be a bit more advanced to also be usable for more  
advanced use cases like Wiki's, revision supportive publishing tools, etc.

What's important to me (and much of the publishing industry I've spoken  
with), is that 'issued' never change. In practice, it will be  
'first-issued', and if we need to call the element 'first-issued' to do  
that, that's fine. That will, however, be of no real use since each entry,  
in my model, can only be issued once.

If you want to re-issue an entry, you supersede it with another. And the  
mechanism for that practice would be defined in an extension to the core.

> Graham doesn't want to outlaw updating in place, he merely wants to be  

I'm not sure what «deal with it» means. I haven't seen a solid use case  
for when modification of 'issued' is useful, either. I know that the  
current practice in the blogging community is that the one date associated  
with an entry can be changed whenever the author feels like it, but I  
thought we had come to agreement that this date isn't 'issued'. Infact, it  
is 'created', 'modified', 'issued' and 'dateline' at once.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:24:24 +0200

On Thu, 22 Jul 2004 07:46:16 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> I love the ambiguity of this stuff. What the heck is a major update?

Whatever makes the author think that the user should read the entry again.  
E.g. not a typo-fix, but pretty much everything else.

> So you're saying that users will see the same post twice in their
> aggregator but that's OK because a 'major' update has been done but
> there is no way to explain to users what exactly is meant by 'major
> update'.

There is a way. It is called «superseding». But if your aggregator doesn't  
support the superseding mechanism, then it will appear as a new entry. Can  
you tell me how RSS Bandit deals with modifications to an entry today,  
when most entries don't even have ID's?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:30:10 +0200

> (view) to be mapped into or layered over the Atom model?

A superseding mechanism _should_ probably be placed outside the core.  
What's important then, imho, is that the core doesn't have a mechanism  
that «competes» with this extension. E.g. drop «updated» and make «issued»  
immutable.

> "first issued" of the multiple versions.

True.

> atom:entry/atom:id is the same as any previous version.

I'm sorry, but I don't follow. How would this work for an immutable  
'issued'?

> down the first published version of the "resource that has many

Hm, not really. The most important date for the publishing industry is  
'first-issued'. If Atom core doesn't support a required 'first-issued' or  
an immutable 'issued' (whatever the element is called), an extension that  
supports it will be of no particular interest.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:35:45 +0200

On Thu, 22 Jul 2004 12:32:33 -0400, Graham <[email-masked]> wrote:

> documents that way.

Why not?

> RSS doesn't.

So? Is it a goal that Atom 1.0 is 100% backwards compatible with RSS?

> Atom 0.3 doesn't.

Atom 0.3 is bound to change in many other areas than this, so that doesn't  
matter either.

> They don't have a <supercedes> element, and no aggregator supports one.

No aggregator needs to, either. A supersede mechanism would be optional.  
What's important is that we don't put a half-way supersede mechanism in  
the core that competes with a more «correct» and advanced supersede  
mechanism.

>> an update of that particular entry, but a brand new one.

I don't say so. Who says so, is the publishing industry, and everyone else  
that publishes stuff that are a bit more professional than a personal  
weblog. And I hope that Atom, in the end, can cater for those needs as  
well as the personal weblog author's.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 15:47:45 +0200

On Thu, 22 Jul 2004 10:25:47 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> By the way I dispute that the W3C supercedes documents.

That's okay, but I disagree with you. Whatever you place in the word  
«supersede»; what W3C does, is to replace an older specification with a  
new one. And this practice is commonly known as «superseding». W3C even  
uses the word «supersede» themselves: «Other documents may supersede this  
document»[1].

> A spec has two URIs, the URI that identifies a version of a technology
> (e.g. http://www.w3.org/TR/REC-xml) and one that identifies the actual
> iteration of that document (e.g.  
> http://www.w3.org/TR/2004/REC-xml-20040204).

These URI's are orthogonal. The problem with Atom is that the current view  
is only to cater for the first of those URI's you mention. Each version of  
an entry doesn't need to be represented in HTML. The HTML document can be  
the latest version at all times, while the older versions of it can be  
retrievable as Atom entries, represented through a superseding mechanism.

> If I only go to the main URI for a W3C document then to me the changes
> happened in place.

Yes, but that is how it appears to you, as a reader. What actually  
happened «under the table», is that each newer version of a specification  
superseded an older one. This is very common practice, not only in W3C.

____
[1] The first paragraph in the section «Status of this document» in <url:  
http://www.w3.org/TR/html40/>.

---

From: Dave Pawson <[email-masked]>
Date: Sat, 24 Jul 2004 14:58:48 +0100

>From which, logically, a major update to a book creates a new title?
No.

Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 24 Jul 2004 12:12:40 -0700 (PDT)

> practice, not only in W3C.

Who cares what happens under the table? We are
discussing a syndication format used for displaying
metadata to readers not for accurately describing the
custom features of every CMS in the world.

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 21:48:42 +0200

On Sat, 24 Jul 2004 12:12:40 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> Who cares what happens under the table?

Even though it's under the table, it's still very visible, seeing that  
_every_ W3C specification that has a previous version, links to it. Every  
version has a unique and retrievable URI, and every newer version  
supersedes an older one.

> We are discussing a syndication format used for displaying
> metadata to readers

That's maybe what you are interested in. I'm primarily interested in how  
Atom can be used and understood by machines and programs. If that data can  
be worked like hand-in-a-glove by a program, the program can easilly  
present it to a human reader, if that's what the program's intention is.

> not for accurately describing the custom features of every CMS
> in the world.

That's not what I'm trying to do either.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 24 Jul 2004 15:53:09 -0700 (PDT)

> when most entries don't even have ID's?

http://www.imc.org/atom-syntax/mail-archive/msg07673.html

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 24 Jul 2004 16:08:03 -0700 (PDT)

--- Asbjørn_Ulsberg <[email-masked]> wrote:
> 
> Okay. How is it different, then, when an entry
> reappears in an entry  
> without an ID, and when an entry that supersedes an
> old one, does?

I have no idea what you are asking. How does an entry
reappear in an entry? What does one entry superseding
another look like in an RSS feed? 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 01:10:11 +0200

On Sat, 24 Jul 2004 15:53:09 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

>> Can you tell me how RSS Bandit deals with modifications to an entry
>> today, when most entries don't even have ID's?
>

Okay. How is it different, then, when an entry reappears in an entry  
without an ID, and when an entry that supersedes an old one, does?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 01:24:51 +0200

On Sat, 24 Jul 2004 16:08:03 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> reappear in an entry?

Sorry, I'm tired. An entry reappears in a feed, of course. If an entry  
without an ID reapperas in a feed (due to modifications), how is that  
different from an entry that supersedes another one, shows up?

> What does one entry superseding another look like in an RSS feed?

Since RSS supports extensions via namespaces, they would semantically be  
almost the same, with different ID's and with a <publishing:relation />  
element that points to the ID they supersede.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 24 Jul 2004 16:49:40 -0700 (PDT)

> different from an entry that supersedes another one,

When an entry [with a link or guid which has been
previously seen] reappears in a feed then RSS Bandit
silently updates the title and content of the entry it
has stored on the local machine. If the entry appears
with a different permalink or guid then it is treated
as a brand new entry. 
 
> element that points to the ID they supersede.

Gotcha.

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 27 Jul 2004 23:13:34 +0200

On Sat, 24 Jul 2004 16:49:40 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> When an entry [with a link or guid which has been previously seen]
> reappears in a feed then RSS Bandit silently updates the title and
> content of the entry it has stored on the local machine. If the entry
> appears with a different permalink or guid then it is treated as a
> brand new entry.

Exactly. Not having support for revisions would be the same as not being  
able to recognize the entries today. Although the latter problem doesn't  
have a solution, the first one has. It's just to support the revision  
mechanism. That's either about parsing the atom:id, or supporting the  
superseding mechanism.

Either way, it would improve the current situation for both consumers and  
producers, and I don't think it's very difficult doing an  
ID.LastIndexOf(":") and getting the substring of that to check if you've  
seen anything like this before (that would be the algorithm for NewsML  
URN's as atom:id's).

>> Since RSS supports extensions via namespaces, they would
>> semantically be almost the same, with different ID's and with a
>> <publishing:relation /> element that points to the ID they
>> supersede.
>
> Gotcha.

What? Where? How? Why?

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 16:16:51 -0600

> last-time-a-major-revision-was-made when displaying

Okay, I thought I understood, but your response to DateSurvey[1] got me 
wondering again.  You've indicated -1 to "Modified: the most recent 
date on which any aspect of the entry's content changed" and +1 to 
"Updated: the most recent date on which the publisher wishes to draw 
attention to the entry's having changed".  Is it that you want a Date 
Construct that could contain EITHER "modified" OR "updated" (as defined 
above) without specifying which of the two it is?

I don't suppose supporting "updated" REQUIRES "content producers ... to 
differentiate between last-time-a-type-was-fixed and 
last-time-a-major-revision-was-made"--they could either draw attention 
to every typo fix, or never bump Updated, no matter how drastic the 
change--but it certainly leaves the door open for content producers who 
wish to do that.

I guess I'm just having trouble seeing how "modified" could get a -1 if 
"updated" is getting +1.  A 0 for "modified" I could understand, but 
what pain is it going to cause, given that supporting "updated" already 
at least allows, even if not requiring, the distinction to be made?

[1] http://www.intertwingly.net/wiki/pie/DateSurvey

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 15:49:10 -0700 (PDT)

> above) without specifying which of the two it is?
...
> [1] http://www.intertwingly.net/wiki/pie/DateSurvey

I couldn't see a scenario where having modified added
value. In a world where modified & updated exists then
content producers and aggregators are now being asked
to differentiate between last-time-a-type-was-fixed
and last-time-a-major-revision-was-made when
displaying content which at best would be very
arbitrary and would vary from tool to tool. 

If only modified exists then it isn't at all useful
since a reader can't tell if the change was an
insignificant change such as moving some whitespace
around or a significant one. 

If only updated exists, then readers can assume that
this date is always significant while content
producers are no worse off than if modified existed
(since they'll still have to make the decision as to
whether the change is significant enough to call
attention to or not). 

Thus I don't see modified adding any value. If it
doesn't add any value then it shouldn't be in the
spec. 

=====

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 17:28:05 -0600

> whether the change is significant enough to call

Okay, I think that clears up my misunderstanding for the most part.

The risk I see in having only Updated is that some people are probably 
going to bump it every time they fix a typo, which, if that does happen 
very often, will result in readers NOT being able to assume that the 
date is always significant.  Modified might serve as a bucket to siphon 
off less useful data which otherwise would pollute Updated.

> arbitrary and would vary from tool to tool.

...but there's still one thing I don't understand.  What is going to be 
more arbitrary if we have both?  The value in Updated is likely to be 
more dependable (as an indicator of significant change), as noted 
above.  Even if (with only Updated) people WOULDN'T pollute Updated 
with data that would have gone into Modified, if it existed, I don't 
see people's decisions regarding whether to call a change significant 
or trivial being more arbitrary if both exist.

So I'm guessing that you're saying one of more of the following:

* that interleaving entries that have only modified, entries that have 
only updated, and entries that have both, possibly from different 
feeds, will have arbitrary results.

* that deciding whether to sort by Modified or Updated (only 
considering one of the two) will be an arbitrary decision.

The latter I don't see a problem with--pick one or let the user decide. 
  But the former is a reasonable argument.  Aggregators would probably 
have to generate a sort field which contained the user's preferred 
sorting date for entries that had both, and whichever (if either) of 
the other two existed for entries that only had one.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 11:54:36 +1000

On 30/7/04 8:49 AM, "Dare Obasanjo" <[email-masked]> wrote:

> value.

some aggregators load entries into their own database/model, and would
prefer to avoid the dump/parse/reload everytime they see that entry (ie.
until if falls off the bottom of the feed) if the XML says it hasn't
actually changed.

'modified' is useful for machines, 'updated' is useful for humans.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 19:44:16 -0700 (PDT)

> 'modified' is useful for machines, 'updated' is

How does modified help here if you already have
updated? I am an aggregator author and if I was going
to do what you describe I'd use the updated value not
the modified value. Why would I reparse the entry if
no significant changes had been made? 

=====

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 13:11:02 +1000

On 30/7/04 12:44 PM, "Dare Obasanjo" <[email-masked]> wrote:

>>> I couldn't see a scenario where having modified added value.
>>> 
>> some aggregators load entries into their own database/model, and would prefer
>> to avoid the dump/parse/reload everytime they see that entry (ie. until if
>> falls off the bottom of the feed) if the XML says it hasn't actually changed.
>> 
> How does modified help here if you already have updated? I am an aggregator
> author and if I was going to do what you describe I'd use the updated value
> not the modified value.

consider this sequence:

    07:50 entry created
    07:59 entry published
    08:15 typo noticed, fixed, published
    09:30 feedback arrives, major change, updated
    10:15 fubar on a link URL, fixed, published

not too unusual.

if you retrieved the feed every hour on the hour, then you would see each
distinct version ... but if you only key off <updated> then you won't know
that the link in the 09:30 version is broken (nor would you have refreshed
your cache with the typo correction of 08:15).

>Why would I re-parse the entry if no significant changes had been made?

<significant to machines> != <significant to humans>

A typo isn't significant, including typos in URLs (unless it was so
egregious that it would possibly justify a footnote). The typos in URLs I'm
thinking of would be stupid things like "htp://www.example.com/foo.html" or
"www.example.com/foo.html" or even "http://www.example.com/foo.html ".

Are you saying you would ignore such corrections?

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 20:49:44 -0700 (PDT)

--- Eric Scheid <[email-masked]> wrote:

> updated? I am an aggregator

So we're back to debating the difference between
significant and insignificant changes? We might as
well start arguing about how many angels can dance on
the head of a pin. 

Fixing a bad hyperlink in a post is a significant
change to me and it is a change that affects humans
consuming the content not just machines. 

=====

---

From: Eric Scheid <[email-masked]>
Date: Fri, 30 Jul 2004 14:32:45 +1000

> well start arguing about how many angels can dance on

The difference is simple: it's significant if the publisher says it is,
while modified is there are *any* changes. Can't be any simpler.

We don¹t have endless debates as to what constitutes a "summary", so why do
we need to do the same for "update"? It's a subjective content-related
element, same as <title> and even <date> (aka <dateline>).

> consuming the content not just machines.

some pedants would argue that fixing "there" to be "their" is a significant
change. 

e.

---

From: Ken MacLeod <[email-masked]>
Date: 30 Jul 2004 00:54:34 -0500

Given my interpretation of the dates in the format-01 spec, here are
some test cases based on those interpretations.  I am hoping that
others who are proposing new dates or different interpretations would
take and adapt these so that we have a better idea of what is being
proposed.

Here are my interpretations of the format-01 dates, as far as my
understanding of them dating back to when Atom started.  It's not that
*my* interpretations are any more right than anyone elses, but the
spec simply doesn't say what interpreation was decided.

format-01:modified

    System modification time.  This will change any time the user
    saves the entry (even if there are no differences), any time the
    entry is copied or restored without preserving the modification
    time, or for any number of other reasons.  However, publishing
    systems should take care that this date does not change
    non-deterministically, as that will cause increased bandwith,
    consumer processing, and possibly repeated displays of the entry
    to the user.  This is more accurately the "last modified" time, as
    from the HTTP header for the entry EditURI resource.

format-01:issued
    This date should not be confused with the Dublin Core date of the
    same local-name.  This date as used by current Atom 0.3
    implementations and unchanged in format-01 is more accurately the
    "display date", a date the publishing system or user says should
    be displayed for this entry when it is presented.  The user or
    publishing system might change this date at any time, but there is
    no significance specified or associated with it changing.

format-01:created
    This is for publishers purposes.  Consumers may ignore it.

Here are some of the tests:

= Consumer tests =

CONSUMER-IGNORES-CREATED

    Subscribe to test feed [[ note to editor: reference test feed with
    creation date 1958-11-14... ]].  Confirm the date '1958-11-14'
    does not appear in any prominent location for the entry (it is ok
    if the date appears in an "advanced", "properties", or "view
    source" location).

CONSUMER-DISPLAY-DATE

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:issued 1979-03-17... ]].  Confirm the date
    '1979-03-17' appears as the displayed date for the entry.  Refresh
    the feed or wait for the feed refresh interval to pass, the date
    will have changed.  Confirm the date '1980-03-17' as the displayed
    date for the entry in the summary and/or entry views.

    Note: The consumer may or may not visibly indicate to the user
    that the entry has changed, this is not considered part of this
    test.  The tester should check the date in the summary view, if
    available, as well as re-select or navigate to the entry after it
    updates to check the new display date.

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be set to a datetime on or
    after the 1980-03-17 datetime to cause the "change of the entry"
    to be recognized. ]]

    [[ Note to WG: This is disputed, the RSS Bandit implementation
    preserves the first date and does not overwrite it.  Confirm
    intent. ]]

CONSUMER-DOES-NOT-SEE-MODIFIED

    Subscribe to test feed [[ note to editor: reference test with
    format-01:modified 1970-01-01 ]].  If the consumer does not
    intentionally display modification dates, confirm the date
    '1970-01-01' does not appear in any prominent location for the
    entry (it is ok if the date appears in an "advanced",
    "properties", or "view source" location, or if the consumer
    normally displays modification dates in addition to the display
    date).

CONSUMER-SEES-MODIFIED-AND-CONTENT-CHANGE

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:modified 1965-03-11... ]].  Confirm the
    content contains "This is 1965-03-11."  Refresh the feed or wait
    for the feed refresh interval to pass, the content will have
    changed.  Confirm the content contains "This is 1966-03-11."

    Note: The consumer may or may not visibly indicate to the user
    that the entry has changed, this is not considered part of this
    test.  The tester should re-select the entry after it updates to
    check the new content.

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be set to 1966-03-11 to cause
    the "change of the entry" to be recognized. ]]

CONSUMER-DOES-NOT-SEE-MODIFIED-CHANGE-WITHOUT-CONTENT

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:modified 1967-11-27... ]].  Confirm the
    content contains "This is 1967-11-27."  Refresh the feed or wait
    for the feed refresh interval to pass, the "modification date" has
    changed but the stored content should not have changed.  Confirm
    the content still contains "This is 1967-11-27."  If the consumer
    always indicates change when the Atom format-01:modified date
    changes, confirm that the change is indicated; if the consumer
    takes a further step to see if the content changes before
    indicating change, confirm that no change is indicated (because
    the content has not changed).

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be set to 1968-11-27 to cause
    the "change of the entry" to be recognized; however, some
    consumers may still perform other tests before indicating
    change. ]]

CONSUMER-DOES-NOT-SEE-CHANGE

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:modified 2000-06-14... ]].  Confirm the
    content contains "This is 2000-06-14."  Refresh the feed or wait
    for the feed refresh interval to pass, the stored content should
    not have changed.  Confirm the content still contains "This is
    2000-06-14."  If the consumer would normally indicate that an
    entry changes, confirm that it does not indicate that this entry
    has changed.

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be not be changed so that the
    "change of the entry" is *not* recognized.  The content of the
    second request should be different than the first. ]]

= Publisher tests =

Will follow later, sleep now.