Subject: Re: Propose partial consensus on dates

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

(Apologies if this appears twice - I received an incomprehensible bounce when
attempting to send) 

* First, quoting Graham <[email-masked]>
> > And <updated>? I liked that. Sam liked it. It solves a major problem 
> > (we can't go to version 1.0 without a real mechanism for flagging 
> > updated entries - and the <supercedes> nonsense is a non-starter).

Instead of labelling a _mechanism_ as "nonsense", could you please qualify
the failures of an explicit mechanism for "superseding".

* Then, Tim Bray <[email-masked]>
> Er it's possible I may have conflated "updated" and "modified"... 
> someone want to explain the difference?

I am -1 on using "Updated". Part of the reasoning should be found in this
simple question: Any "modification" is an "update".

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 00:04:53 +0200

> I was summarizing my position from previous discussion about it. See 
> here:
>   http://www.imc.org/atom-syntax/mail-archive/msg06940.html

Ok, to recap:

1. You're afraid that if A supersedes B supersedes C, and B is missing, you
won't know that A supersedes C.

* I see no harm in keeping explicit information for every supersede. This is
hardly going to be a common bandwith-eating bloat problem.
* I see no harm in keeping _just_ the first supersede. If entry C supersedes
A, it must also (naturally) supersede B if C newer than B.

-- 
Arve Bersvendsen

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 00:15:18 +0200

* Dare Obasanjo
[On Display]

> 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. 

This argument makes sense to me.

> > I (too?) believe that there is rough consensus on
> > 'created' and 'modified',
> > 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. 

Atom is both an archival and publishing format. As for "rough consensus",
read Tim Bray's definition on the date.

> 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.  

Note that I dislike the "Update" date as such, as I prefer "re-issuance" with
explicit pointers to the entries affected (read, "Supersede"). This is both
for archival reasons, and for feed->aggregator use in more formalized
processes than the typical blog scenario. I would hate to see Atom
disqualified by default.

An aggregator that doesn't support revisioning would never suffer any data
loss when any supersede/replaces mechanism is used, compared to today.

(I'd like to remind people that Dublin Core didn't pull a rabbit out of some
random magic hat when they defined replaces/isVersionOf/hasVersion as
refinements of dct:relation)

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 21 Jul 2004 19:25:06 -0400

Arve Bersvendsen wrote:
> Disregarding "atom as feed format", and looking at the "atom as
> archive format": How is one going to represent a complete history
> of revisions with this model, when multiple, and differing
> entry:id's are disallowed?
	Your database key would have to be a compound key built from
"atom:id + atom:updated". Of course, to be really precise you should make
the key "atom:id + atom:modified", but, it doesn't look like folk are
supporting atom:modified...

		Bob wyman

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 10:29:06 +0200

* Eric Scheid 
> every page edit "supercedes" the prior version of the page, but does not
> cause a new URI to be created for the new version... the page retains the
> same canonical URI.

Note that the resolvable URI need not change. Any supersede mechanism would
carry a reference to an entry:id, not a refereence to <link rel="alternate"
/>

-- 
Arve Bersvendsen

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 10:51:06 +0200

* Robert Sayre
> 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 can be handled both in case of the revisioning CMS, and in the
non-revisioning one.

In the (current) non-revisioning one, you would simply contiue your current
practice.  In the case of the revisioning one, you could also write your
'<strong>update</strong>, and in addition ticking a "major edit" box.

-- 
Arve Bersvendsen

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 11:12:03 +0200

> supporting atom:modified...

I was not refering to what my database scheme should look like, I already
know how to do that.

I was asking: How can I keep several distinctly different posts, all with the
same ID in the same (archive/edit) feed? I'm going to answer: With today's
wording for ID as "globally unique", the validator pukes on this. Example:

<URL:http://www.virtuelvis.com/temp/dupe-id.xml>
<URL:http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.virtuelvis.com%2
Ftemp%2Fdupe-id.xml>

-- 
Arve Bersvendsen

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Thu, 22 Jul 2004 11:41:50 +0200

* Graham wrote:
> > Disregarding "atom as feed format", and looking at the "atom as archive
> > format": How is one going to represent a complete history of revisions 
> > with
> > this model, when multiple, and differing entry:id's are disallowed?
> 
> The spec doesn't say that anywhere. It's technically not an error 
> (currently) to have several entries with the same id in a feed if they 
> are different versions of the same entry. If we mean it to be 
> allowable, this might even provide a valid use case for <modified>.

I've interpreted "globally unique" as "may not appear twice". The feed
validator, and it's authors seem to agree with me:

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Fri, 23 Jul 2004 04:34:14 +0200

* Sascha Carlin

> (btw, shouldn't it be 
> published instead of issued? Or is publishing refering to the technical 
> task of publishing? My English is not that good.) 

The Merriam-Webster Online dictionary [1] has the following definitions for
the verb "issue", which applies to the way 'issued' is suggested used:

'5 : to appear or become available through being officially put forth or
distributed'

and the transitive sense:

'2 a : to put forth or distribute usually officially <government issued a new
airmail stamp> <issue orders> b : to send out for sale or circulation :
PUBLISH c British : PROVIDE 2b, SUPPLY'

___
[1] Curse them for using POST for searches. http://www.m-w.com/ is the
closest I can send you

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Fri, 23 Jul 2004 22:21:49 +0200

> > - Organizations/tools/people to support the use case that an entry may 
> > only be issued exactly once, with an immutable 'issued' date.
> 
> Can you fill us in why this case might need to be handled differently 
> from entries that change?

Because there are organizations out there that issue something _exactly
once_. If they, for some unknown reason, need to change the content of what
they have already released, they cannot simply change the content of what
they have written, they have to release a new entry that supersedes the old
one.

One such notable process is medical journals here in Norway.  If the treating
part or the patient want an entry in the journal changed, they cannot simply
go back and change that entry. They have to issue a new entry in the journal,
and state that this entry supersedes a given previous entry.  This is a legal
requirement.

The blogging model of dated, and often linked, entries is a good fit for the
typical medical journal. The "feed" notion of a journal also fits pretty well
with the (again, Norwegian) legal requirement that a patient has a legal
right to access his jorunal.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sat, 24 Jul 2004 16:44:24 +0200

* Dave Pawson

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

Regardless of what happens to the title:
<URL:http://www.imc.org/atom-syntax/mail-archive/msg06782.html>

-- 
Arve