Subject: Re: Date Options Survey

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

* Tim Bray:
> You're entitled to that opinion, but I talked it over with Paul and 
> Sam, and we agreed that we had a good-enough shared understanding to do 
> some information gathering.  

Ok, to be clear: I have answered the survey with MY understanding of one
specific date: issued.

My specific understanding is: "issued" == "first-issued" == does not change,
even if the entry changes. A date that essentially would be a timestamp for
when an entry's state was set to "publish".  I am +1R on that.

Another understanding of "issued" is what Movable Type thinks the "issued"
date is now: The user-changable date that is attached to an entry. In Movable
Type, this date is always equal to "created".  I am, at the very least, a -1
on that. 

-- 
Arve Bersvendsen

---

From: "Roger B." <[email-masked]>
Date: Sat, 24 Jul 2004 04:22:14 -0500

> when an entry's state was set to "publish".  I am +1R on that.

Arve: Let me see if we can make some practical progress on this front.
Here's a scenario:

Let's say it's next year, and Atom 1.0 is released into the wild. And let's
say your argument has carried the day, and the spec ships with a required,
static atom:issued element.

When I put a potentially dynamic date in that element, how will you know?
How will Sam and Mark validate the nature of my dates? In concrete,
user-facing terms, how will your publishing app break if/when one of my
dates changes? In concrete, user-facing terms, how will your aggregator
break if/when one of my dates changes?

(My guesses: You won't, they won't, it won't, and it won't.)

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

---

From: Dave Pawson <[email-masked]>
Date: Sat, 24 Jul 2004 10:46:22 +0100

> Type, this date is always equal to "created".  I am, at the very least, a -1

And mine are different again from these.
I guess that's what's happening with the survey? Trying to find out if
there is support for the ideas there? If they come down one way or
another, clarity can be sought prior to wordsmithing the spec?

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

---

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

On Sat, 24 Jul 2004 10:06:14 +0200, Arve Bersvendsen <[email-masked]>  
wrote:

> My specific understanding is: "issued" == "first-issued" == does not  
> change, even if the entry changes. A date that essentially would be a
> timestamp for when an entry's state was set to "publish".  I am +1R on
> that.

This is my understanding as well, so +2R on that one from me.

> Another understanding of "issued" is what Movable Type thinks the  
> "issued" date is now: The user-changable date that is attached to an  
> entry.
> In  Movable Type, this date is always equal to "created".  I am, at the
> very least, a -1 on that.

I'm -2 on it. I would actually rather not have an 'issued' at all, than  
having the issued Movable Type currently employs.

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

---

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

> When I put a potentially dynamic date in that element, how will you know?

No one but you will, but then; you're abusing the element. That's like  
using <table> for layout in HTML today. Machines will (or at least should)  
expect that you put tabular data in it (because that's what W3C says it  
should contain), but the data you have in it isn't tabular. Hence, you're  
abusing the <table> element.

> How will Sam and Mark validate the nature of my dates?

There is oceans of things the validator can't spot. How can the HTML  
validator spot abuse of the <table> element, or the <h1> element for that  
matter? «The data inside <table> is not tabular!» or «The text inside the  
<h1> tag is not a heading!» is very unlikely to ever be seen, because it  
is impossible to spot by a program.

> In concrete, user-facing terms, how will your publishing app break  
> if/when
> one of my dates changes?

No other publishing application will know about your dates other than your  
own. I don't understand this scenario.

> In concrete, user-facing terms, how will your aggregator break if/when  
> one of my dates changes?

Firstly, the context of when you first wrote and published the entry will  
be unknown. Secondly, any order of the entries on the assumption that  
'issued' equals 'first-issued' will break.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 00:47:09 +1000

> own. I don't understand this scenario.

I think Roger is referring to a situation not unlike the following:

09:00 - your publishing application retrieves the feed,
        finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
09:30 - some edits are made, new entries created, etc
10:00 - your publishing application again retrieves the feed
        finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
10:01 - techs run screaming as the publishing application
        erupts in a fiery blaze of sparks?

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 01:14:56 +1000

oops! sloppy copy/paste.

this one has the entry retrieved at 10:00 with a different 'issued' value.

        finds an entry id=#1 with 'issued'=2004-07-24T08:15Z

e.

---

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

>         erupts in a fiery blaze of sparks?

No. What is more probable to happen, is the following:

   09:00 - Our aggregator is offline due to upgrades

   09:00 - The owner of feed X publishes a set of new entries

   09:30 - The owner of feed X edits an entry with id=#1, and
           gives it a new 'issued' date.

   10:00 - Our aggregator retrieves feed X and finds an entry
           id=#1 with 'issued'=2004-07-24T08:15Z

   10:01 - No one will ever know that the entry was originally
           issued at 2004-07-24T08:00Z

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 07:03:55 +1000

On 25/7/04 6:08 AM, "Asbjørn Ulsberg" <[email-masked]> wrote:

> [Our aggregator misses the change]

that may well happen too.

it doesn't answer what your aggregator will do when it does come across an
entry which has a changed 'issued' date though.

remember: many blog feeds include entries covering many days, so unless your
aggregator is a real slow poke and only schedules a retrieval once a month
you are likely to see the changed 'issued'.

what does your tool then do? catch fire? dump core? reject the feed? reject
the entry? ignore the changed value?

e.

---

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

On Sun, 25 Jul 2004 07:03:55 +1000, Eric Scheid  
<[email-masked]> wrote:

> it doesn't answer what your aggregator will do when it does come across  
> an entry which has a changed 'issued' date though.

Currently, it won't do anything, because it doesn't exist. We will try to  
create it after Atom's model as closely as possible, and if we face a  
mutated 'issued', I'm not sure how we should react. We might insert it as  
a supersede of the previous entry we have in our database, or at least as  
a version of the entry under the same ID, but without knowledge of its  
relation to the previous entry we have.

Nothing will catch fire, but it is loss of important data not to know when  
the entry was first issued. And that's a loss I won't swallow very easilly.

---

From: "Roger B." <[email-masked]>
Date: Sun, 25 Jul 2004 02:21:04 -0500

Asbjorn: Okay, so as with Arve, we've established that this can't be
mandated, can't be validated, and in addition, the origin of my date has no
impact on your use of the same date element in your publishing environment.

So we're left with this:

> be unknown. 

It will be known to the extent that I want it known. I've given it a date of
2004-08-10, and that's all you need to know. It's my writing, and I will
decide the context. If I want to write it in 2003 and make you think I wrote
it in 2004 (or vice versa), that's my business.

> Secondly, any order of the entries on the assumption that

Two questions:

(1) Define "break". What exactly will happen?

(2) If "issued" is actually "first-issued", then why would an aggregator
ever check that element for any instance of atom:id after seeing it the
first time?

---

From: "Roger B." <[email-masked]>
Date: Sun, 25 Jul 2004 02:43:31 -0500

> having the issued Movable Type currently employs.

Asbjorn: Yet another question, from another angle. 

If an MT user puts mutable dates in issued and you put immutable dates in
issued, how is the consumption of your feed compromised by the consumption
of the MT user's feed?