Subject: Date Options Survey

From: Tim Bray <[email-masked]>
Date: Fri, 23 Jul 2004 14:57:23 -0700

Is up for WG input at http://intertwingly.net/wiki/pie/DateSurvey

Please at this time do *not* argue about the definitions or 
classifications, this is meant as a blunt-edged data gathering 
exercise.  -Tim

---

From: "Roger B." <[email-masked]>
Date: Fri, 23 Jul 2004 18:29:17 -0500

> exercise. 

Tim: That made it tough, because I had to -1 some things that would have
been better described as -1R, or "Atom would suffer from having this as a
required element". While I personally think four core date elements probably
amounts to two too many from a view-source POV, I'm not actually opposed to
any of them as long as they're optional.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Tim Bray <[email-masked]>
Date: Fri, 23 Jul 2004 16:28:54 -0700

> any of them as long as they're optional.

Roger, why don't you add a section for commentary at the bottom of the 
page below the table and drop that in.  It's useful info. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Fri, 23 Jul 2004 20:20:00 -0600

> any of them as long as they're optional.
Perhaps the following list of choices could be used to express that:

-2: I won't be able to use Atom if this is included
-1: Atom would suffer from having this included
0: I don't care.
0NR: I don't care if it's in Atom or not, but if it is, it should NOT 
be REQUIRED in every Entry
+1: Atom would benefit from having this included, and I don't care 
whether it's REQUIRED in every Entry
+1NR: Atom would benefit from having this included, but it should NOT 
be REQUIRED in every Entry
+1R: Atom would benefit from having this included, and it should be 
REQUIRED in every Entry
+2: I won't be able to use Atom if this isn't available, and I don't 
care whether it's REQUIRED in every Entry
+2NR: I won't be able to use Atom if this isn't available, but it 
should NOT be REQUIRED in every Entry
+2R: I won't be able to use Atom if this isn't available, and it should 
be REQUIRED in every Entry

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 23 Jul 2004 19:59:01 -0700

>Perhaps the following list of choices could be used to express that:

Folks:

Could we *please* just let the poll happen without trying to tweak it 
do death while it is running? It's a poll, nothing more. It gives 
folks a visual way of saying "oh, this seems to be going that way". 
We can have different ones later, if we want. We can re-run this one 
in light of new material if we want. We can run away screaming, if we 
want.

Tim's purpose is a good one: see how folks are thinking without 
having to wade through the messages, which are less than clear at 
times.

It's the weekend. Let's give it a few days and see what it ends up 
looking like. It might be a big waste of time, but that's no big deal.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Roger B." <[email-masked]>
Date: Sat, 24 Jul 2004 02:45:44 -0500

> do death while it is running?

Paul: It would be pointless to tweak it now anyway... adding/changing items
would warp the results. So yeah, it's better to finish an untweaked poll,
and if things still look muddled, try a tweaked one later.

---

From: Sascha Carlin <[email-masked]>
Date: Sun, 25 Jul 2004 11:57:19 +0200

Just to document the current votes.

I ignored R/NR and just summed the numbers.

Of 20 votes, with a maximum total of 40:

  - 4 for created
  - 14 for dateline
  - 13 for issued
  - 13 for modified
  - 7 for updated

Of 20 votes, with a maximum total of 20 saying it needs to be there:

  - 0 for created
  - 3 for dateline
  - 9 for issued
  - 9 for modified
  - 2 for updated

16 votes agree in 'issued' and 'modified' should be the only REQ dates, 
3 say 'dateline' should be the only REG (one includes 'updated').

I know the vote is fresh and it's weekend, but as the strongest 
participants already have voted, I just try it:

* Include 3 dates in Atom core, 'dateline, 'issued' and 'modified'.

* Make 'issued' and 'modified' REQ, 'dateline' OPT.

'dateline' defaults to 'issued', modified does for new entries, too. If 
you modify the entry, 'issued' would still have the old value and 
'modified' would be updated.

Since there are use cases where 'created' and 'updated' would be of 
great value, create a module/extension for them. If you want to use it, 
you'd inlude 'dateline, 'issued' and 'modified' as mentioned above plus 
'created' and 'updated'. This way applications using core Atom would not 
suffer and could still interpret your feeds.

If you (feed provider) don't want to use the extension, your (the 
programmers) application (using the extension) should interpret created 
= issued and updated = modified. This way you would still be able to use 
feeds with less information getting the most out of them.

Programmatically this would mean that applications need to store at 
least three dates: the date an entry is being made publically available 
(never changing), a date set by an author (changing at author's will) 
and the last date the entry was modified in any way (changing 
automagically).

For the extension to work the application needs to store two more dates. 
First the date the new entry is opened for the first time (never 
changing), second a date the author marks as bringing new/changed 
information to the entry (changing at author's will, e. g. by using a 
checkbox 'major update' as is used in some wikis).

I think this model would fit 80% of the most common use casing (using 
Atom core), leaving enough room for specialised applications (using the 
extension).

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205

---

From: Sascha Carlin <[email-masked]>
Date: Wed, 28 Jul 2004 10:38:26 +0200

Seems like nobody is interested? Is my suggestion so odd?

Regards, Sascha

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 02:18:24 +0200

> * Make 'issued' and 'modified' REQ, 'dateline' OPT.

I would love to see this in the specification and not to mention; followed  
by the tool vendors, but my current faith tells me that is _never_ going  
to happen. Current tools don't even conform to the RSS 2.0 specification  
of 'pubDate'[1], which is much older than Atom.

Why the tool vendors think that «Its value is a date, indicating when the  
item was published» means «Either 'created' or 'published', possibly set  
to something completely different by the user», is beyond my  
comprehension. Why most tools also only provide one date is something I  
don't understand either.

So, requiring 'issued' and 'modified' will just generate heaps of bad data  
for years to come.

> 'modified' would be updated.

As Laurent Le Meur writes[2], 'dateline' does not fit for the semantic  
placed on 'pubDate' and 'dc:date' in current tools. What for example  
Movable Type means with its single date, is 'created', 'sort-date' and  
'user-date' of the following reasons:

   1. 'created'

      When you create (press the [Save] button) an entry in Movable Type,
      the date gets set to that point in time on the server. When the
      entry returns, you get an «Authored on» field in the web form set
      to this date.

   2. 'sort-date'

      The «Authored on» field is modifyable for the user. At any point
      in time, the user may change this date, thus removing its previous
      'created' semantics. A good reason to change «Authored on» is to
      have the entries re-arranged in your feed or on the front page of
      your blog.

   3. 'user-date'

      As already mentioned, the «Authored on» field is modifyable. In
      addition to point 2., this field may be edited by the user to
      reflect just about anything. The user applies his or her very
      own semantic on the date by modifying it, without the possibility
      to tell anyone what he or she means with the date.

I will not express what I feel about this now, but regardless of my  
feelings, it's obvious that Movable Type neither supports RSS' or Atom's  
semantics with any of their dates. I think you will have a hard time  
managing to find a term for the MT-date in Dublin Core, at least. And  
neither 'created', 'issued', 'modified' or 'dateline' fits.

Other tools have different semantics applied to their date(s). They are  
very unlikely to fit with MT's semantic, and would make it even harder to  
create a good name for this date element. 'date' or 'display-date' would  
probably be the best term to use, but I would recommend the specification  
to say «SHOULD NOT use» on this element, as it is completely without any  
meaning, since it's a compound of many different dates and semantics.

I've made a separate suggestion to how we can solve this:

<url: http://www.imc.org/atom-syntax/mail-archive/msg07940.html>

The proposal is basically to require one date, but not say which one.  
Still, each date element would have either «SHOULD», «MAY» or «SHOULD NOT»  
associated with them, which orders the date in preference as to what we  
would like an Atom entry to contain. Requiring much more than «a date» at  
this time, is not feasible, I think.

> least three dates:

I would really enjoy it if all tool vendors came running now, saying «We  
will support all of 'issued', 'modified', 'created', 'date' and 'dateline'  
in the next version of XYZ», but I doubt that will happen.

____
[1] <url:  
http://blogs.law.harvard.edu/tech/rss#ltpubdategtSubelementOfLtitemgt>
[2] <url: http://www.imc.org/atom-syntax/mail-archive/msg07955.html>

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