Subject: Propose partial consensus on dates

From: Tim Bray <[email-masked]>
Date: Wed, 21 Jul 2004 11:18:21 -0700

I know this isn't officially in the current-work list, but a lot of 
people have been putting furious energy into the dates discussion.  As 
co-chair I *think* I detect rough consensus on part of the problem.  If 
I'm right, then we can retire that part of it and focus on what's left 
over.

BTW, on this one, *rough* consensus may be the best we can do, I'm 
enumerating what look like strong-majority positions.  As always, the 
list is hard to keep on top of, my reading may be wrong, feel free to 
disagree.

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

NOTES: It seems that substantial amounts of existing software use 
either or both of the "modified" and "display" semantics.  It also 
seems that while some software records the "created" semantic, nobody 
actually does anything with it; on the other hand nobody suggests that 
it causes any problems.

PROBLEMS:
- the name "display" is not that great.  I've seen suggestions of 
"base" and "described".  It occurs to me that in North American 
journalistic lingo, the word "dateline" *exactly* describes the 
semantics.
- it might not be possible to use RFC3339 syntax for "display".  
Existing deployments are not able to use timezones.
- there are a variety of incompatible requirements (some of them quite 
strong) for another date called "issued" which doesn't seem to be any 
of these.

So, we need proposals for:
- a better name than "display".  
<just-tim-not-cochair>I</just-tim-not-cochair> hereby propose 
"dateline"
- what the right format is for "display"
- 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").

NEXT:
- if you disagree that we have rough consensus as outlined, say so, 
nobody's feelings will be hurt.
- if you have brilliant proposals for any of the problems, speak up

  -Tim

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 14:40:13 -0400

> <atom:modified> on the 17th.

Why "must"? We don't have a real use case for it yet. It's certainly 
not very interesting to end users in the way a real Updated date would 
be.

> machine-processable, not free text.

Fair enough.

> <atom:created> on the 11th.  RFC3339.

Maybe.

> journalistic lingo, the word "dateline" *exactly* describes the 

Agreed "display" is not a good. "timestamp" (or "datestamp") might be 
OK.

> strong) for another date called "issued" which doesn't seem to be any 

The only incompatibity I saw was whether it could be changed over time, 
and <updated> solves that problem. <issued> seemed to be the only one 
there's consensus on.

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

Graham

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 Jul 2004 12:29:55 -0700

On Jul 21, 2004, at 11:40 AM, Graham wrote:

>> 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.
>
...
> updated entries - and the <supercedes> nonsense is a non-starter).

Er it's possible I may have conflated "updated" and "modified"... 
someone want to explain the difference? -Tim

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 15:40:06 -0400

On 21 Jul 2004, at 2:48 pm, Tim Bray wrote:

> Er, I think you need to explain the semantics for "updated".  
> Presumably it differs from "modified" in more than name.  I don't 
> understand, so probably others don't either. -Tim

<updated> proposed by Sam here:
  http://www.imc.org/atom-syntax/mail-archive/msg06946.html

Refined by me here:
  http://www.imc.org/atom-syntax/mail-archive/msg07057.html

+1'ed by Sam here:
  http://www.imc.org/atom-syntax/mail-archive/msg07065.html

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 21 Jul 2004 16:01:28 -0400

Tim Bray wrote:
> I may have conflated "updated" and "modified"... 
	The usage that is growing seems to be:
	Modified: At least one byte changed. However the change might not be
significant and worthy of notice if you had already read a previous version
of the entry. Thus, atom:modified would be changed when a publisher did
things like correct spelling mistakes, made minor grammatical errors, or
inserted/modified an advertisement embedded in an entry. Modified would
typically indicate that the form of the entry has changed -- not its
meaning.
	Updated: At least one byte has changed and the publisher considers
the change to be of such significance that readers should consider reading
the entry even if they had read an earlier version. Atom:updated would be
used when adding additional paragraphs to an entry, modifying a position
taken in an entry, modifying the content in such a way that the semantics of
the entry (not just it's syntax) has changed.
	I think that a modification to atom:updated would always require a
similar modification to atom:modified; however, a modification to
atom:modified would not always require a similar modification to
atom:updated.

	At least, I think that's what the distinction is...

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 Jul 2004 13:15:25 -0700

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

Er, exactly.  That's what I meant.  s/modified/updated/g in my 
consensus proposal.  And if you look at my original description of the 
semantcs, that's exactly what I was trying to capture: an assertion by 
the publisher as to when things changed.   -Tim

---

From: Tim Bray <[email-masked]>
Date: Wed, 21 Jul 2004 13:17:05 -0700

> the entry (not just it's syntax) has changed.

I agree 100%.  However, I do not recall seeing consensus around putting 
Modified into Atom, just around Updated.    -Tim

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 16:30:33 -0400

> the publisher as to when things changed.   -Tim

I took that to mean any change (ie Fiddling with punctuation). If you 
meant it to be like <updated>, it can only be required when the 
publisher/tool keeps track of it, which most don't. Otherwise, it's 
useless.

Graham

---

From: "Roger B." <[email-masked]>
Date: Wed, 21 Jul 2004 16:22:37 -0500

> <atom:modified> on the 17th.

Tim: +1 as written. If the element is intended to be used solely for
substantive updates, then it needs to be "may" rather than "must"... many
(most?) tools don't differentiate between "substantive" and "minor" at this
point.

> machine-processable, not free text.

+1, although if any date were to merit "must" status, this would be the one.
I'm fine with an all "may" collection of date elements, though.

> <atom:created> on the 11th.  RFC3339.

+1

> <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose

+1. Works for me, seems descriptive.

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

---

From: Antone Roundy <[email-masked]>
Date: Wed, 21 Jul 2004 15:39:05 -0600

> +1. Works for me, seems descriptive.
+1.  Part of the virtue of "dateline" from my POV is that I wouldn't 
have any preconceived notions of what it means.  If those who DO have 
preconceived notions about its meaning do in fact use it as desired, 
then I can't think of any reason not to go with it.

...and if I pause a moment to think about what it SOUNDS like it might 
mean, then the meaning we're aiming at does seem to fit perfectly.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 21 Jul 2004 16:07:03 -0600

> the entry (not just it's syntax) has changed.
My sense is that more people aren't interested in having both of these 
than are.  I'm satisfied to go with the consensus on this, though I 
lean towards wanting both, but would like to raise one issue.  I would 
think that if a particular feature is desired by a significant minority 
of people, and it wouldn't cause problems for everyone else, then it 
might be worth putting in.  The questions are:

1) How large a minority would need to want something for it to get in?
2) How large a minority (assuming I'm correct that it's a minority) 
wants this?
3) Last but not least, would this in fact not cause problems for those 
who don't particularly want it?

If we don't end up taking both, I'd favor having "updated" as defined 
above, and not "modified".

---

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

> <atom:modified> on the 17th.

+1.

> 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  

+1.

> <atom:created> on the 11th.  RFC3339.

+1.

> strong) for another date called "issued" which doesn't seem to be any of  
> these.

Yes. To just ask some simple questions on 'issued':

   - Do we agree that the current date situation (of RSS) isn't something
     we want to build Atom on?

   - Do we agree that all tools have an action corresponding to 'issued'
     (that is, publishing the resource to the web)?

   - Do we agree that the word 'formal' in DC's description of 'issued'
     outrules that it might be a subjective date?

   - Do we agree that Atom might not only be used and targeted at personal
     weblogs?

If the answer to all of the above questions is «yes» I see no harm in  
requiring tools to provide an 'issued' date. Okay, many people don't  
understand the use for it now, but I've stated on numerous occasions that  
this date is crucial in a publishing process.

E.g., I see no reason _not_ to have an 'issued' date. The only debate,  
after agreeing on having 'issued' as a required date in Atom Core, would  
be if 'issued' can ever be changed. Changing 'issued' would be a way to  
signify «major» modifications, which I think we agree that an 'updated'  
date, or something else, rather should take care of.

If we agree that 'issued' is immutable, and all of the above points, I  
think we agree on the following:

   - 'issued' should be required.
   - 'issued' is an objective, tool-provided date.
   - 'issued' indicates when the resource was _first_ published

If people disagree with this, I'd like to know why. If the «why» is  
because «I'd like to hack my issued date», the answer is «use 'display'».  
If it is because «I'd like to change it to re-issue my entry», the answer  
is «Use 'updated' or any supersede mechanism». If the reasons are any  
other, I'd really like to hear about them.

> <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose "dateline"

Sounds okay.

> - what the right format is for "display"

Probably something close to the author's heart, so at least not required  
UTC.

> defined in a way that would meet at least some of the needs around  

I could easilly loose 'created' in favour of 'issued'. I don't mind having  
both, but 'issued' is, without a doubt, any publishing process' singular  
most important date.

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

---

From: Walter Underwood <[email-masked]>
Date: Thu, 22 Jul 2004 12:26:29 -0700

--On Wednesday, July 21, 2004 11:18 AM -0700 Tim Bray <[email-masked]> wrote:
> - a better name than "display".  <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose "dateline"

"dateline" might be confusing, because of preexisting newspaper usage.
In newspaper usage, a dateline may include a location. From XMLNews:

  <dateline>
  <location><city>Bangkok</city></location>
  <story.date>May 31, 1999</story.date>
  </dateline>
  see: <http://www.xmlnews.org/docs/story-spec.html#element.dateline>

NewsML defines it as:

  DateLine  A natural-language statement of the date and/or place of creation.
  see: <http://www.newsml.org/IPTC/NewsML/1.0/specification/NewsML_1.0-spec-functionalspec_4.html#DateLine>

I like that definition for Atom, but we would need to lose the
"and/or place" part.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Sascha Carlin <[email-masked]>
Date: Fri, 23 Jul 2004 00:52:11 +0200

> <atom:modified> on the 17th.

BTW, I am not sure if I got that right: "modified" should also indicate
the time the entry was published? If yes, -1, see below.

+1

+1

> - the name "display" is not that great.  I've seen suggestions of "base" 
> and "described".  It occurs to me that in North American journalistic 
> lingo, the word "dateline" *exactly* describes the semantics.

Isn't that "deadline"? Err, forget it ;)

> strong) for another date called "issued" which doesn't seem to be any of 

Should be optional, +1

> - what the right format is for "display"

If it's a date, it should be formated as dates are in Atom...

> defined in a way that would meet at least some of the needs around 

"created" != "issued".

Issued should be a requirement, indicating the time the entry was
published for the first time.

And finally, "updated" should be there - optionally.

That would make the following list:

REQ "issued"   - the time the entry was published for the first time

OPT "created"  - the time the entry was created i. e. was saved (inside
                  the publishing system) for the first time

OPT "modified" - the last time the entry was modified without changing
                  the semantical informtion given in the entry
If the entry is modified, this should be REQ

OPT "display"  - an accompanying pointing out an semantically important
                  date to/of the entry

OPT "updated"  - the last time the entry was semantically changed
If the entry is updated, this should be REQ

Regards, Sascha

---

From: "Roger B." <[email-masked]>
Date: Thu, 22 Jul 2004 18:40:45 -0500

> REQ "issued"   - the time the entry was published for the first time

Sascha: If a date element with that definition is a MUST in the Atom spec,
then one of two things happen:

(1) Millions of Atom feeds will be turned off as everyone goes back to RSS
en masse.

...or...

(2) Millions of Atom feeds will violate the spec by stuffing the display
date into the required issued element.

My money's on (2), since that's the path of least resistance for publishers.

Whether or not such an outcome is a problem is a matter of opinion... after
all, it'll be undetectable by the validator, and many consuming apps simply
won't care. So unless you're passionate about the sanctity of
specifications, it might be of little concern. Of course, folks in the Atom
community tend to be precisely the kind of folks who are passionate about
the sanctity of specifications, so who knows?

---

From: Sascha Carlin <[email-masked]>
Date: Fri, 23 Jul 2004 03:13:59 +0200

> then one of two things happen:
[snip]

>> the time the entry was published? If yes, -1, see below.

I know (now, just checked with the drafts) the current drafts consider 
"modified" to be required and indicating many things: first of all, the 
time the entry was published. Since it is the only required date to an 
entry, it is the element current application use to sort entries by and 
display it as the entries' creation date.

Sure I am riding on it, as we say in German, but to me things (in the 
real World) seems to be like this:

(In brackets the elements holding timestamps outlining the described 
tasks. Tasks can be done in any timly order, alone the creation is 
always the first thing to do.)

Someone creates content ("created"). She adds a date to the content to 
outline a tight relation between the information and this date 
("display", could be used to store the date of a talk, if the content is 
an announcement of this talk, for instance). At some point she 
proof-reads it and corrects some errors, typos and alike ("modified"). 
At some point she - because of new information or to correct semantical 
errors - she changes (parts of) the information ("updated"). At some 
point she decides to publish the content ("issued").

Lets asume all these dates make it into an atom feed and into an 
aggregator of some sort (let's asume it's Bloglines and we use it as a 
usual feed consumer to check with our favorite blogs). This aggregator 
uses the dates in the feed to do the following things:

Sort the entries by "issued" to show the user whats new and whats old. 
(We don't want old information, we want the new stuff. For us new stuff 
is what we can read now, but could not 5 minutes ago.)

Well, here is an entry from yesterday which was "modified". Nothing new 
here, just fixed a few typos and glitches in the list code. Bloglines 
marks it as "modified", but keeps sorting it using "issued".

OK, there is an entry issued the day before yesterday, but 
"updated">"issued" -> new information. Let's see this. Bloglines uses 
"updated", if set, to check whether there is new information worth 
reading it. Since "updated" means there is new information and not just 
'a byte changed', we want this entry to be sorted by "updated" so that 
it comes up in the list.

One of our favorite bloggers is on holiday and keeps a journal. Since 
she can't access the internet, she blogs every other day or so. 
Sometimes she forgets to bring all her notes to the internet cafe and 
thus she posts day 6 before day 4. But she is a nice guy and has 
"display" set up correctly, so we can tell Bloglines to sort ascending 
by "display". Automagically, Day 1, Day 2, Day 3, ... appear in the 
semantically correct order.

Perhaps we are curious and want to see how fast Joe blogs his thoughts. 
Bloglines show the date Joe "created" his entry on how to build a better 
syndication format. Wow, 7 month before he "issued" this lenghty paper. 
Must have put much brain power into this.

Of course, these use cases are trivial. I just use them to make it 
easier to get what I mean. Hope that worked ;)

My point is, that there are different times, having different meanings. 
Atom should use the correct term for each date (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.) and give users the 
chance to use all these, if they like to. Meta data is good and 
important, but needs to be described as clearly as possible to be of 
real use.

May I draw your attention to this article: "The five purposes of 
metadata: David Haynes.": 
http://www.cilip.org.uk/update/issues/julyaug04/article3julyaug.html
It is somehow like an executive summary, but brings it to the point. And 
forget about this "Metadata is the future."... It _is_ an executive 
summary ;)

> the sanctity of specifications, so who knows?

This is a political question, too. I am not much of a politician, I am 
just a student of information and library science interested in 
experiencing the creation of a new standard and taking part in some of 
the discussion around it. My goal is to learn and to share - and to help 
to make IT as easy as it can be. Breaking current applications is a 
unpleasant thing to do, sure. But it is not bad nor evil, if it helps to 
make something better.

Wow, this got bigger as intended, and it'S later than I hoped. Going to 
bed and wishing you all good night, Sascha

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

---

From: Eric Scheid <[email-masked]>
Date: Fri, 23 Jul 2004 11:37:05 +1000

>                  If the entry is updated, this should be REQ

+1, mostly. 

I'd prefer "dateline" to "display" as it's more indicative of the
content-nature of the date as opposed to a meta-data-presentational nature
of the word "display".

I agree with Roger B that we can't make "issued" required because the vast
unwashed masses don't have tools that support it in the sense of *first*
published and this will simply result in a million blogs breaking the spec.

I don't see a huge problem in making "dateline" the one required date. This
models very closely to how blogging tools currently work, and I'd be
surprised if the vaunted professional publishing tools don't have the
capability for a dateline.

I'd want "updated" to include semantic changes to non-content parts of the
entry too. Similarly "modified". I wouldn't want "modified" to be munged if
the entry was simply re-written at the XML level (eg. re-ordering of
elements or variations of xmlns:prefixes).

Note that the last "updated" value should be carried forward even when a
particular instance isn't "updated" per se ... thus edition C of {A,B,C} can
be seen as an update of A even if edition B was never retrieved (while
briefly available). On the backend this would probably be implemented by not
forcing a default value into the date field, and then omitting the updated
element if the date field is empty (aka null).

e.

---

From: David Powell <[email-masked]>
Date: Fri, 23 Jul 2004 14:20:45 +0100

> published and this will simply result in a million blogs breaking the spec.

If "issued" is to be made optional, then we need to make some more
fixes, because we would have a situation where once an entry is
modified it is guaranteed to have an objective date - "modified", but
new entries wouldn't be guaranteed an objective date.

The solution, if "issued" is made OPT, is to either:

a) make "modified" REQ even for new entries

b) require either "created" (for new entries), or "modified" (for
modified entries), or both.

I prefer a) - it matches how "modified" dates work in file systems.

-- 
Dave

---

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

On Thu, 22 Jul 2004 18:40:45 -0500, Roger B. <[email-masked]>  
wrote:

> Sascha: If a date element with that definition is a MUST in the Atom  
> spec, then one of two things happen:
>
> (1) Millions of Atom feeds will be turned off as everyone goes back to  
> RSS en masse.

I doubt that. If so, it will (hopefully) only be transitional.

> date into the required issued element.

That will also be transitional. Tools will already need to enhance their  
functionality to be Atom-conformant. Atom is _not_ RSS backward  
compatible. It has never been. And that's why Atom will be _better_ than  
RSS, and not just alternative syntax.

> after all, it'll be undetectable by the validator, and many consuming
> apps simply won't care.

Many consuming apps won't care. Sure. Many consuming apps will care, as  
well.

---

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

On Fri, 23 Jul 2004 11:37:05 +1000, Eric Scheid  
<[email-masked]> wrote:

> I agree with Roger B that we can't make "issued" required because the  
> vast unwashed masses don't have tools that support it in the sense of
> *first* published and this will simply result in a million blogs
> breaking the spec.

Transitionally, yes. This has been brought up on so many occasions now,  
that I need to ask: Is the current consensus that Atom should be backwards  
compatible with RSS and that no tools should change in order to conform to  
the Atom 1.0 specification?

> I don't see a huge problem in making "dateline" the one required date.

It's basically just an alternative, more subjective way to express  
'issued', so I see absolutely no reason to require it.

> This models very closely to how blogging tools currently work

Why is the current practice in the blogging world of such major  
significance, while current practice other (more professional) areas of  
minor or no interest? This doesn't model how the publishing industry  
currently work, and the model will be very difficult to implement outside  
the world of Movable Type and LiveJournal et al, because it doesn't make  
sense anywhere else.

> and I'd be surprised if the vaunted professional publishing tools don't
> have the capability for a dateline.

Some do, some don't.

---

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 08:27:49 -0400

Asbjørn Ulsberg wrote:
> that I need to ask: Is the current consensus that Atom should be 
> backwards  compatible with RSS and that no tools should change in order 
> to conform to  the Atom 1.0 specification?

The question about backwards compatibility with RSS is a red herring.

  - - -

RSS 0.91 had no item level date.

RSS 1.0 had something simply called "date" and if you follow the 
definition of this date, you find "Typically, Date will be associated 
with the creation or availability of the resource."

RSS 0.93 introduced a date named "pubDate", defined as "Its value is a 
date, indicating when the item will become available".  In 2.0, this 
changed to "indicating when the item was published. If it's a date in 
the future, aggregators may choose to not display the item until that date".

  - - -

At some point in this discussion, a myth was created that RSS dates were 
correspond to "dc:issued" ("dc:available" is a better match, IMHO), and 
that "dc:issued" is mutable.

The one thing that can be observed, based on experience with RSS, is 
that if a slot for a mutable date is not provided, people will use the 
slot provided anyway.

The charter says "The working group will use experience gained with 
RSS...".  We have experience with how people have misused RSS.  And we 
can observe the results: they blame the aggregators.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Sat, 24 Jul 2004 22:35:38 +1000

> the Atom 1.0 specification?

The more change needed for adoption the slower the adoption will be. Both
'issued' and 'updated' will require changes to blogging tools. With
'updated', there will be an immediate payoff to implementing that change,
with aggregators being able to discern the changes of interest amongst the
noise of minor modifications.

The same *cannot* be said for 'issued'. For the major active constituency
for which atom is being developed for, they simply haven't recognised any
value or utility to know the first-published date. There would be no payoff
for the pain.

> 'issued', so I see absolutely no reason to require it.

My point is simple: it's better to have only one date be required rather
than a plethora, and if we have to choose just one I pick 'dateline',
because it will deliver the most bang for the buck for the most users who
are already in the community. Extra fields which will only be used by a
minority, no matter how much they jump up and down about the importance of
the BDS&M of their policies and procesures, should be optional as required.

e.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 24 Jul 2004 09:35:09 -0600

On Saturday, July 24, 2004, at 06:35  AM, Eric Scheid wrote:
> Both
Given that the major active constituency for which Atom is being 
developed has never had the option of having both an issued date and an 
updated date, I don't know that we can make definitive statements about 
how useful they'll (we'll) find the one versus the other. In my first 
pass at Date Options Survey, I said "0" for Issued, but then I got 
thinking about how I'd used Updated, and changed to +1.  Here's my 
thinking:

Some users will want to see each entry only once, whether it gets 
Updated or not.  Other users will want to see it again every time it's 
Updated.  Each is likely to want the date ordering to be based on the 
date that interests them.  The reason for the person wanting to see 
Updates wanting to sort by Updated is obvious enough--to them, an 
update is new news.  But a person who only wants to see it once is 
likely to consider it new news only as of the time it was first issued. 
  Thus, knowing when it was first issued is important for their sorting 
order.

A concrete example: Let's say I'm syndicating somebody else's newsfeed 
on my website. On Monday, shocking revelations come out about 
government corruption, and a story about it appears in the feed.  It 
gets displayed on my site.  On Wednesday, the publisher notices a 
significant factual error and fixes it.  They bump the Updated date to 
bring it to the top of the feed for people who care about updates.  
That's the right thing to do, but that doesn't make the news story 
fresh.  It's two days old, and I'd rather have my site showing the 
fresh news story about how the stock market is crashing today.  As an 
individual reader, I may have the same preference.  I've been away from 
my feed reader for 3 days.  I've already heard the government 
corruption story from five different sources, so I don't need it to 
come to the top.  It's still a new Entry for me, since I've been away 
from the feed reader, but it's not fresh news, so I want it to fall to 
the bottom of the list.

---

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

> The question about backwards compatibility with RSS is a red herring.

Yes. That's why I wonder why it's brought up every time «immutable  
'issued'» is mentioned. If we were to specify Atom to be backwards  
compatible with RSS, Atom would be RSS.

> RSS 0.91 had no item level date.

So, Atom already breaks backwards compatibility with RSS 0.91.

> with the creation or availability of the resource."

So, it's specified as 'issued', but used more as a combination of  
'issued', 'created' and 'dateline' in most publishing tools.

> the future, aggregators may choose to not display the item until that  

Also specified as 'issued', but used as a combination of 'issued',  
'created' and 'dateline' in most publishing tools.

> that "dc:issued" is mutable.

Yes. I agree that this is a myth, and nothing more.

> that if a slot for a mutable date is not provided, people will use the  

I think such a slot should be provided. I just don't understand why it  
must be 'issued'. Any other mutable date works just fine with me. Multiple  
'issued' elements even works; see:

<url: http://intertwingly.net/wiki/pie/PaceMultipleIssued>

But _one_ mutable 'issued' doesn't work at all. Why do people tend to  
squeeze the current practice of RSS' dates into 'issued', when nothing I  
know of supports that conception? The current RSS date may change whenever  
the author wants. The current RSS date is _not_ 'issued'. So, why should  
atom:issued ever change?

> can observe the results: they blame the aggregators.

Shouldn't we try to rectify this, then? And while we're in the rectifying  
process, having a look at how more professional, century old practices  
that are proven to work, functions, wouldn't hurt, imo.

---

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

On Sat, 24 Jul 2004 22:35:38 +1000, Eric Scheid  
<[email-masked]> wrote:

> The more change needed for adoption the slower the adoption will be.

Of course. This will be a balance between «What do we want?» and «How fast  
do we want it to be supported?». I'm most concerned about «What do we  
want?» at this point, as I have strong beliefs in the adoption of Atom,  
almost no matter how much incompatible it will be with RSS.

I'm not saying we should break compatibility as much as XHTML 2 is with  
previous versions, but I don't agree that we shouldn't change anything  
either. Some things must change. Some things must break backwards  
compatibility with RSS. Regardless of these dates, that's a fact. Why  
can't 'issued' break this backward compatibility as well, then?

> Both 'issued' and 'updated' will require changes to blogging tools. With
> with aggregators being able to discern the changes of interest amongst  
> the noise of minor modifications.

With immutable 'issued' + 'supersede', this will apply as well. No one  
needs to implement support for it, even, because it's supported already.

> value or utility to know the first-published date. There would be no  
> payoff for the pain.

Maybe not for the weblogging community, but I am saying that more  
professional publishing processes will have very much value from it.

> than a plethora

If only one date should be required (when was that ever made an issue?), I  
would requre 'issued', since that is the most important date in a  
publishing process.

> and if we have to choose just one I pick 'dateline', because it will
> deliver the most bang for the buck for the most users who are already
> in the community.

I will probably never even parse the 'dateline' date in the tools I'd be  
writing for Atom.

> Extra fields which will only be used by a minority

Do you see professional publishers like BBC as a minority? What defines  
«minority»? The number of publishers? The number of readers that publisher  
has?

---

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

> needs to implement support for it, even, because it's supported already.

by "supported" you mean today's aggregators will clutter up my daily feed
reading with multiple versions of the essentially same entry?

-1

e.

---

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

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

> must be 'issued'.

Looking at DateSurvey, there is very strong support for 'dateline', so I
don't think anyone is saying it must be 'issued'. It has been said however
that if there is just one date field then it will get abused.

e.

---

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

-1

"essentially same" meaning the bulk of content the same, just one extra
footnote.

just like this damnable email itself?

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 04:06:45 +1000

-1

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 04:23:52 +1000

-1

have I made my point yet? apologies to everyone!

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 04:29:53 +1000

> Thus, knowing when it was first issued is important for their sorting

For me, sorting on 'updated' doesn't make much sense, and I am someone who
*does* want to see updates. I would sort on 'dateline', not 'updated', not
'issued', because this gives me the best sense of what they are writing
about.

My feed reader of choice currently marks unread items in bold, and if it
detects a change (via diffs since we don't have 'updated' yet) it marks it
in bold again. (Incidentally, this means that if I haven't got round to
reading something it doesn't matter if it has been updated or not). If I
sort by 'dateline' (or pubDate as in current practice (not spec)), then I
can see something has been updated because it's down the page, nestled
amongst a bunch of things I've already read. This positional context signals
to me that it is old, it was probably read, and it's now been updated.
Jumbling updates in with new news doesn't help me ... I'd start to read from
the top of the entry and then be confused because it looks so familiar. For
updates, I'd want to know I should probably glance/scroll to the bottom of
the entry, because that's where by custom most people write their update
footnotes.

I'd also prefer to sort on 'dateline' not 'issued', because I'd prefer to
read things in the date order that they are about (content wise), and not
the order in which someone got around to writing up their notes. Sorting by
'dateline' not 'issued' also means that any new entry with an older date
stands out ... it's down the page, nestled amongst a bunch of read things.
This is a subtle signal that it's been issued in out of date sequence, since
I normally read things as they become available, and to take that into
consideration regarding accuracy due to elapsed time effects on
recollection. Sorting by issued doesn't give me that signal.

If it's below the scroll, I will still find it because my feed-reader of
choice gives me an unread count for each feed.

So, sorting by 'dateline' makes more sense to me than sorting by 'updated'
or 'issued'. I'd still make use of 'updated'. I still don't know what I'd do
with 'issued'.

e.

---

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

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

> don't think anyone is saying it must be 'issued'.

Many people on this list have argued that the current practice is so and  
so, and that's why 'issued' can't be so and so. If we agree that the  
current practice is with a date that has almost nothing in common with  
'issued', I believe that practice can't be covered by an 'issued' element,  
and thus proclaiming what current practice is, means nothing, at least not  
when talking about the 'issued' element. Right? :-)

> It has been said however that if there is just one date field then it  
> will
> get abused.

I've always said that the more dates, the merrier. Personally, I find it  
very difficult to believe that it will be problematic for any tool to  
produce both 'issued', 'modified' and 'created', seeing that absolutely  
all tools I have ever worked with (both in the weblogging world and  
outside of it) does all of these actions:

   - If a tool can create entries, it should provide a date for it.
   - If a tool can issue entries, it should provide a date for it.
   - If a tool can modify entries, it should provide a date for it.

If a tool can't provide any of these dates, I really don't understand how  
that tool can work at all. The only date of the above I really _need_, is  
'issued', though. Why is it too much to require that tools provide that  
date? Because they don't do it today?

---

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

> reading with multiple versions of the essentially same entry?

They already do that, don't they? If not, how do current aggregators  
differentiate entries that has no ID?

---

From: Sascha Carlin <[email-masked]>
Date: Sat, 24 Jul 2004 22:49:18 +0200

> or 'issued'. I'd still make use of 'updated'. I still don't know what I'd do

(I describe dates in words because there is no consensus about the 
format dateline should have.)

What exactly does the date in dateline refer to? We had the use case 
'journal', where entrys should be sorted day by day in the correct 
order, using 'dateline'.

That's a valid usecase, but what does it mean for other use cases? Take 
an entry in a department blog announcing a department meeting on this 
Tuesday, 9am localtime.

Taking the semantics from the first use case, 'dateline' should be 'this 
Tuesday, 9am localtime'. So my aggregator should display this entry on 
top of the list until either another entry comes with a dateline > 'this 
Tuesday, 9am localtime', for instance an entry about the department's 
summer party taking place at the restaurant across the street on '20th 
September 2004. Again, this entry should be displayed on top until, ... 
You get it.

So there may be situations ruled by local policies where we have entries 
with a dateline far far in the future.

Another problem with dateline - at least I feel it's a problem - is 
hidden in the the following use case: let's assume the entry about the 
summer party mentioned above. It's taking place in September, but the 
author - the dep. secretary - announces a meeting in August to plan the 
party. What would then be the 'dateline'? The meeting or the party? The 
secretary is not very into all this web-stuff and thinks that keeping a 
filofax is much more effective. So she may think, ok, it's about the 
party, right? I put the party's date inside this form field.

To make a long story short: 'dateline' is not an objective date. It 
depends on the authors view and we sure cannot believe all people around 
the world would have the same opionion about what date to put inside the 
same entry's dateline field.

'issued', 'updated', 'modified' and 'created' are objective. They define 
a clear point in time making a clear assertion about a certain step in 
the life on an entry/document (in Information Retrieval, all content 
entities are documents).

Sure 'dateline' is a neat thing to have. But it is not error prone 
enough to count on it.

---

From: Sascha Carlin <[email-masked]>
Date: Sat, 24 Jul 2004 23:48:52 +0200

Sorry for double posting, I forgot something to second my point.

> Sure 'dateline' is a neat thing to have. But it is not error prone 

'dateline' and its idea to come from professional journalism/publishing. 
Can we really rely on Joe Average to do the job of a long-studied and 
trained journalist?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 00:53:02 +0200

On Sat, 24 Jul 2004 22:49:18 +0200, Sascha Carlin <[email-masked]> wrote:

> To make a long story short: 'dateline' is not an objective date.

No, it is highly subjective, which effectively makes it useless as a  
«stand-in» for any other dates.

> 'issued', 'updated', 'modified' and 'created' are objective.

Right on.

> Sure 'dateline' is a neat thing to have. But it is not error prone  

Seeing that it will be provided by most blog publishers, I don't see the  
value in requiring it either. I don't understand what good it does for  
consumers, when present, that 'issued' and 'modified' can't cater for.  
Requiring 'issued' and 'modified' makes much more sense, as they can  
always work as stand-in dates for 'dateline', but it can never be the  
other way around.

---

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

> so, and that's why 'issued' can't be so and so.

Asbjorn: That's a misunderstanding, from what I can see. I suspect most
folks would be happy adhering to a "professional publisher's" definition of
"issued"... I know I would. Just don't try to force me to provide such a
date by making it a required element, 'cause it ain't gonna happen.

I can accommodate your practice, and you can find a way to accommodate mine.