Subject: Re: Date Options Analysis: Issued

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

* Roger Benningfield
>> 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.
> 
> Arve: Let me see if we can make some practical progress on this front.
> Here's a scenario:
>
> 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?

Roger: I cannot enforce what you or others put in their feeds. The validator
cant enforce what someone puts in their feed - as long as it is syntactically
valid, it _is_ syntactically valid. I can't stop you from putting
1337-01-01T13:37:00Z as a permanent constant in all of your dates, if that is
what you wish.

Similarily, the W3C can't force web authors to create semantically sane
documents. They can't stop someone from using tables from layout. They can't
stop SEO spammers from putting pargraph content into heading elements.

What the W3C can do, however, is to provide a clear wording on what an
element means, and how it is to be used.

What we can do, is to provide clear wordings on what the different elements
within the atom namespace means, and how they SHOULD and SHOULD NOT be used.
If neccesary, we can even say how an element MUST and MUST NOT be used.

A clear wording on what an element really does _mean_ is a tool for
application vendors to facilitate reliable interoperability.  

-- 
Arve Bersvendsen

---

From: "Roger B." <[email-masked]>
Date: Sat, 24 Jul 2004 05:53:17 -0500

> application vendors to facilitate reliable interoperability.

Arve: Perhaps I should be happy with half my questions answered, but
consider me greedy... I want the whole enchilada.

For the sake of argument, we can agree that a static date can be neither
mandated nor effectively validated. So what are the real-world repercussions
of using a dynamic date? How will your publishing app and/or aggregator
break when I change a date in my feed? What unintended consequence will I
face?

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

---

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

On Sat, 24 Jul 2004 05:53:17 -0500, Roger B. <[email-masked]>  
wrote:

> So what are the real-world repercussions of using a dynamic date?

Since I've answered your questions regarding this, what is the solid use  
case for ever changing 'issued'?

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

---

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

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

> what is [a] solid use case for ever changing 'issued'?

my computer clock is wrong and has been publishing everything with the year
1901. whoops. I fix it, fix the data, and republish.

e.

---

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

On Sun, 25 Jul 2004 01:13:01 +1000, Eric Scheid  
<[email-masked]> wrote:

> my computer clock is wrong and has been publishing everything with the  
> year 1901. whoops. I fix it, fix the data, and republish.

Okay. You made an error when you first issued. A good use case which I can  
support. That should be included in the specification text in the lines of:

«The atom:issued date is immutable, and SHOULD never change. In practice,  
it reflects the entry's first date of issuance. If, however, the  
atom:issued date is erroneous due to date misconfigurations, it MUST be  
modified to reflect the correct issued date of the entry. It SHOULD NOT be  
modified to re-issue the entry. For re-issuance, see  
[extension:supersede].»

Or something like that.

---

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

> case for ever changing 'issued'?

Asbjorn: Happens every day. 

(1) User is on vacation and posts (via email) three messages documenting
three days of her trip. She hits "send", and all three messages get posted.
However, she has no way to specify the publish date from within her mail
client, so all three posts end up with today's date. When she gets home, she
logs in and fixes the problem.

(2) User posts via an API client that doesn't support user-specified pub
dates. Later, she has to log in and fix the problem.

(3) User keeps a rigid, daily diary, but forgets to post until 1AM the next
day. So he posts quickly before bed, and goes back in the morning to fix the
problem.

(4) User posts three entries that are meant to be read in a specific order,
but forgets to take her blog's reverse chronological order into account. She
has to login and fix the problem.

(5) User is cheating on his wife, and suddenly realizes that his blog entry
from three days ago indicates that he was playing golf, when he told her
that he was playing golf *four* days ago. She he has to login and fix the
problem.

(6) User posts "into the future" about an event or whatever, and the event
gets pushed back. He has to login and fix the problem.

(7) JournURL-specific: User posts an entry, but forgets to check the
"weblog" box on the posting page. Her entry shows up in the forum, but not
in her blog. When she spots the missing post four days later, she edits it
to make it show up in her blog, and updates the pub date so her readers
won't miss it.

I could go on like this for pages. People are people. They change their
minds. They do dumb things. Sometimes they're evil. Sometimes the world is.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 22:40:13 +0200

> Asbjorn: Happens every day.

There are use cases, but if you don't even _want_ 'issued' in Atom Core,  
why would you want to destroy it?

> three days of her trip. She hits "send", and all three messages get  
> posted. However, she has no way to specify the publish date from within
> her mail client, so all three posts end up with today's date. When she
> gets home, she logs in and fixes the problem.

I'd say she should use 'dateline' instead.

> dates. Later, she has to log in and fix the problem.

Dateline.

> (3) User keeps a rigid, daily diary, but forgets to post until 1AM the  
> next day. So he posts quickly before bed, and goes back in the morning
> to fix the problem.

Dateline.

> (4) User posts three entries that are meant to be read in a specific  
> order, but forgets to take her blog's reverse chronological order into
> account.

Ordering of elements _inside_ the publishing system should not be based on  
the data being served outside of it. I know Movable Type works like this,  
but I can't make myself to think anything else than that this behavior is  
wrong.

Other, more professional content management systems order elements based  
on explicit order if you tell them to. E.g., they get ordered  
automatically by issued date until you interfere and say «I want this to  
go there instead». Destroying perfectly good data because the CMS behaves  
bad is not a good use case to allow for a destroyed 'issued' date.

> (5) User is cheating on his wife, and suddenly realizes that his blog  
> entry from three days ago indicates that he was playing golf, when he
> told her that he was playing golf *four* days ago. She he has to login
> and fix the problem.

He has to log in, I presume. This would be in the same ally as the use  
case as when an issued date is set wrong because of bad server  
configuration, so the data needs to be fixed afterwards. This should of  
course be possible, but nothing the CMS encourages the user to do. E.g.  
not as available as the 'Created' field in Movable Type.

> (6) User posts "into the future" about an event or whatever, and the  
> event gets pushed back. He has to login and fix the problem.

What does he fix then? Doesn't he just delete the entry, or removes the  
'Publish' state? Why does the date have to change, when the entry isn't  
even issued yet? Or do you think it's perfectly okay that an entry appears  
in a feed, but have 'issued' set to a future date?

> "weblog" box on the posting page. Her entry shows up in the forum, but  
> not in her blog. When she spots the missing post four days later, she
> edits it to make it show up in her blog, and updates the pub date so
> her readers won't miss it.

One could maybe see the two entries as such separate as different 'issued'  
is okay, but this should be much more elegantly solved in the CMS. If a  
user edits the entry, checks the «weblog» box and issues the entry again,  
it should appear in her feed with the recent issued date, while reside  
with first one in the forum.

> minds. They do dumb things. Sometimes they're evil. Sometimes the world  

People should maintain dates that are interesting to people. Machines  
should maintain dates that are interesting do machines. People _may_ be  
allowed to edit the dates that are interesting to machines, but should not  
be encouraged to do so.

---

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

> why would you want to destroy it?

Asbjorn: I've said this repeatedly on the list and on the wiki, but I'll say
it yet again.

I do not wish to "destroy" your definition of "issued". In the spirit of
compromise, I would be more than willing to embrace it. I'm not convinced it
needs to be in the core, given that millions of feeds can't supply it, but
I'm flexible on that as well.

*All* I am saying at this point is that "issued" cannot be required. That's
it. If it's required, it's a non-starter. If it's optional, our little
corner of the world will live as one.

> I'd say she should use 'dateline' instead.

I agree. Unfortunately, you've been advocating "issued" as a required
element, which means that whatever would normally go into "dateline" will
just have to go into "issued" as well.

> I know Movable Type works like this,

You can keep on thinkin' it, but we're not here to tell Six Apart how to
build their apps.

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 25 Jul 2004 21:21:36 -0400

> needs to be in the core, given that millions of feeds can't supply it,

Hardly millions, and perhaps more like "currently don't have a means to supply
it".  If it's something that offers compelling functionality it's highly
unlikely those tools will remain deficient.

> just have to go into "issued" as well.

Is it a matter of issued being "defined" before dateline "evolved"?  Is there a
more evolved consensus on which is better in the *context of a feed* instance?

> You can keep on thinkin' it, but we're not here to tell Six Apart how to

And I'd leave it for them to make comments about their own tools and
desire/ability to adapt.  They've been mighty flexible in the past.

-Bill Kearney
Syndic8.com

---

From: "Roger B." <[email-masked]>
Date: Sun, 25 Jul 2004 20:56:37 -0500

> unlikely those tools will remain deficient.

Bill: I haven't seen any Blogger, MT, TypePad, or LJ blogs supplying the
immutable issued upon which we seem to have settled. Adding it up, we're
getting into "millions" territory.

> Is it a matter of issued being "defined" before dateline "evolved"?  

Not from what I've read of the arguments put forth here. It's a matter of
"issued" being defined by the traditional publishing industry and Dublin
Core, and that definition being considered a crucial and essential part of
Atom's date selection. 

> desire/ability to adapt.

As would I. In fact, that's almost exactly what I said: "...we're not here
to tell Six Apart how to build their apps."

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 27 Jul 2004 22:19:24 +0200

> getting into "millions" territory.

The immutable issued is not anything anyone has settled on, and have never  
existed as writing in any specification. That would be the primary reason  
for its lousy support in existing tools. A better example of bad support,  
although good specification language (that proves that you're right about  
this), is the immutable atom:id.

Since the beginning, atom:id has been specified to be globally unique and  
that it MUST NOT change. I believe that it does change in most tools,  
however, since it's not stored with the entry in an RDBMS (or wherever)  
statically, but generated rather dynamically.

> Core, and that definition being considered a crucial and essential part  
> of Atom's date selection.

It is, but I've come to the conclusion that it's better to have optional  
high-quality dates in the entries, than having required low-quality ones.  
Therefore, I propose requiring at least one date, but making all of  
'issued', 'modified' and 'created' SHOULD's, and 'dateline' MAY. I'll try  
to write up a pace for this if this is something everyone can live with.

We still need to find a solution for 'first-issued', though, since Ken and  
I have agreed on that «flat» publishing systems (that is, systems without  
a separation between stories and story instances; e.g. revisioning  
systems) only have the latest instance of a story, and therefore also at  
all times the metadata about the latest instance.

I'll try to explain this with some ASCII art:

   [Story]
   ID

   [StoryInstance]
   IsVersionOf
   VersionID
   Issued
   Created
   Modified
   Title
   Body

'StoryInstance.IsVersionOf' is a foreign key for 'Story.ID'.  
'StoryInstance.VersionID' is unique for each 'StoryInstance.VersionID'.  
Each StoryInstance is issued created and issued exactly once, but can be  
modified several times. When re-issuing the Story, a new StoryInstance is  
created with a new 'VersionID, 'Created', 'Issued' and 'Modified' set.

The above is a rough description of how a revisioning CMS _could_ work.  
They could also, without any problems, work with just one table, but the  
above sketch makes it clearer that we're really talking about two levels  
within each «story».

Non-revisioning CMS's have flattened the above view, effectively deleting  
'StoryInstance.IsVersionOf' and 'StoryInstance.VersionID'. That makes the  
one 'Story.ID' the ID's of all instances, but as that ID at all time only  
holds the latest instance, 'StoryInstance.Issued' will refer to the latest  
issuance as well.

However, knowing when a story was first issued is important. Not so  
important that we MUST require it in Atom (Core), but so important that we  
SHOULD have it, and so important that for all «flattened» systems, we  
shold have an atom:first-issued date. The alternative is to have multiple  
atom:issued elements, but as Ken noted; few, if any, that have such a flat  
CMS wil ever store the individual 'issued' dates, but only store the last  
one.

This is a big furball to swallow, as I'm used to having separate stories  
and instances, which means that a story instance only can be issued once,  
and once only. For a story instance, there is no such thing as  
'first-issued' or 'last-issued'; it's just 'issued'. Just as the same with  
'created'; you can only create something once.

> [...] I said: "...we're not here to tell Six Apart how to build
> their apps."

If the specification tells them to e.g. ensure global uniqueness in their  
ID's; yes we are. Maybe we can't require 'issued' or 'first-issued' in  
Atom Core v 1.0, but we should at least encourage everyone to put them in,  
either so that everyone can improve their tools, or so that those who have  
those dates available already, can serve them.

---

From: Walter Underwood <[email-masked]>
Date: Thu, 29 Jul 2004 15:57:10 -0700

--On Tuesday, July 27, 2004 10:19 PM +0200 Asbjørn Ulsberg <[email-masked]> wrote:
>
> It is, but I've come to the conclusion that it's better to have
> optional  high-quality dates in the entries, than having required
> low-quality ones.

It isn't high-quality and low-quality, it is professional and
casual publishing. I can't afford an editorial staff to do the
picky stuff for me. A professional publication can afford it.

How about an immutable='true' attribute? That allows professional
publishers to assert their policy of immutable issuance dates.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 20:39:59 +0200

On Thu, 29 Jul 2004 15:57:10 -0700, Walter Underwood <[email-masked]>  
wrote:

> casual publishing.

To me, professional publishing provides higher quality, at least for these  
dates. Whenever I find a date in current feeds, there is absolutely no way  
to know what that date actually means. When I find a 'created' date in  
more professional formats, I know _exactly_ what it means. The former  
gives me lower quality, the latter higher.

But this is nitpicking. It doesn't matter.

> publishers to assert their policy of immutable issuance dates.

I'm much more +1 for defining profiles. Ken MacLeod has proposed something  
in this direction (though not syntactically identical to it):

   <feed version="1.0">
     <profile xmlns="http://purl.org/profiles/professional-publishing" />

     [....]
   </feed>