Subject: Those dates again

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 00:09:32 +0200

This is probably not a popular issue, but as we don't seem to have reached  
any consensus on the matter, I've blogged some on the dates of Atom:

<url: http://www.virtuelvis.com/quark/archives/188.html>

I'm trying to explain why especially 'issued' is so essential as it is,  
and what other dates might be useful to an Atom entry. I probably don't  
cover everything (I'm pretty confident that I don't), so please feel free  
to comment on anything I write about in the entry. Here's an ultra-short  
summary of the entry:

This is the dates Atom seems to need:

  * Issued
  * Modified
  * Created
  * Display

Only the two first should be required. The two last will probably be  
available most of the time, but they are not very useful seen through my  
publishing binoculars and from a data model point of view.

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

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 20 Jul 2004 15:41:59 -0700 (PDT)

--- Asbjørn_Ulsberg <[email-masked]> wrote:
> > 
>   * Issued
>   * Modified
>   * Created
>   * Display
> 
> Only the two first should be required. 

Agreed. 

> The two last
> will probably be  

As an aggregator author I'd never use either of least
two dates but assume they are of use to someone. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

---

From: Sascha Carlin <[email-masked]>
Date: Wed, 21 Jul 2004 00:48:57 +0200

>  * Display

What does Display mean?

Created seems to me to be important for use inside the application the 
entry is created in/from. An editor could be presented with a view of 
all entries created in a certain period of time to see how old a piece 
information really is.

Regards, Sascha

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

---

From: James M Snell <[email-masked]>
Date: Tue, 20 Jul 2004 17:10:29 -0600

> two dates but assume they are of use to someone. 

Why assume that?  If they are not useful as part of the core model (which 
I agree they are not, btw) then they shouldn't be defined by the core 
model.  If a certain subset of folks want 'em, let that certain subset 
define them as extensions.

> My dungeon will have its own qualified medical staff complete with 
> bodyguards. That way if a prisoner becomes sick and his cellmate 
> tells the guard it's an emergency, the guard will fetch a trauma 
> team instead of opening up the cell for a look.
> 
> 
> 
> 

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 01:17:46 +0200

> What does Display mean?

Sam Ruby introduced the 'Display date' term[1] and explained it as:

   Date 2: Display

   This date is effectively a user entered date. It means whatever the
   user wants it to mean. It can be fictitious, it can be in the future.
   It can even be fanciful (Samuel Pepsys comes to mind).

   This date is effectively part of the content. Accordingly, if the
   display timestamp changes, the updated timestamp should also change.

   We could define it as a string, but an ability to internationalize
   and search on this field is desirable. One would rarely sort on this
   field. Having an ability to express perceived relative local time in
   this field is also desirable.

> entry is created in/from.

Sure. For archives, it's probably also important, but I'm not sure it's  
necessary to require the date, because it's not very useful in most cases,  
if the provided 'issued' and 'modified' are (as) objective and reliable  
(as can be).

> An editor could be presented with a view of all entries created in a
> certain period of time to see how old a piece information really is.

Yes, it's an useful date, but probably nothing it's worth requiring in all  
Atom entries. I'm not sure about this, though. If there is a strong use  
case of the date, I have no problems with requiring it, since it's just as  
easy to provide this date as 'issued'. Basically: the more (factual)  
dates, the merrier.

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg06946.html>

---

From: Sascha Carlin <[email-masked]>
Date: Wed, 21 Jul 2004 01:32:39 +0200

> Sam Ruby introduced the 'Display date' term[1] and explained it as:
[snip]

Ok, thanks. On the client side this could also be used to mark an entry 
as 'read on a certain date'. Cool thing ;)

> Yes, it's an useful date, but probably nothing it's worth requiring in 
> all  Atom entries. I'm not sure about this, though. If there is a strong 
> use  case of the date, I have no problems with requiring it, since it's 
> just as  easy to provide this date as 'issued'. Basically: the more 
> (factual)  dates, the merrier.

Created != Issued, but for many applications this would suffice. But 
even now most CMS have the ability to mark an entry as 'Draft' resp. 
'Not published yet'. So you create content, proof read and then issue 
it. Later you modify and/or update it and at some point users read it 
(see Display above).

Hmm... Shouldn't we make a distinction here, too? Modified means just 
cleaning up, fixing errors, and Updated means really updating the 
content to represent current information.

Required dates should be Issued and Modified (these do suffice for most 
use cases), but I strongly hope, coming from an IA/LS background, that 
the other dates including Modified/Updated will be there, too - so that 
people who need this information can have it without breaking the standard.

Regards, Sascha

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 20 Jul 2004 16:33:02 -0700 (PDT)

> Sam Ruby introduced the 'Display date' term[1] and

On pressing Sam about this date I seem to remember he
eventually described it as being akin to issued. If
issued and modified are in the feed I can't see any
reason why an aggregator would need some fictitious
and bogus additional date. 

The main point of contention seems to be that some
people felt that 'issued' is to formal a term to
define what is meant by 'user entered publish date in
some CMS' so they wanted a fourth date field to
capture this semantic. 

I think this is an unnecessary distinction. 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 01:57:01 +0200

On Tue, 20 Jul 2004 16:33:02 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> eventually described it as being akin to issued.

I think that would depend heavily on what the subjective date is used for.  
If it's a «publish this entry in the future» mechanism, I agree, but if  
it's a fictional, random, totally unreliable date, I don't.

If the subjective date is altered by the user to make the entry appear  
before another on his HTML front page (this is how Movable Type works,  
btw), it's not 'issued', but a sorting mechanism. If the subjective date  
is edited or altered by the user because she actually meant to publish the  
entry two hours earlier, that's not 'issued', since 'issued' is formal.  
Formal is factual. Factual dates shouldn't lie.

If the subjective date is hacked by the user to assert something like  
«Noon on Wednesday», it is not 'issued'. If 'issued' is displayed as «Noon  
on Wednesday» that's not up to the author, but to the reader. The format  
of 'issued' should be ISO-8601 and not an arbitrary string.

E.g., I can't agree that 'Display' is 'issued', at least not for all uses  
of 'Display' or other subjective dates.

> If issued and modified are in the feed I can't see any

I agree, other than that if 'Issued' is allowed (by not saying otherwise  
in the specification) to be subjective and bogus, we really just have  
'Modified' as a reliable date. Only that Movable Type lets the user alter  
'Modified' as well, of course. So, basically, we have _no_ reliable dates  
today. I think this should be fixed.

> some CMS' so they wanted a fourth date field to

True.

> I think this is an unnecessary distinction.

In a strict publishing sence, the distinction is very important, as I try  
to explain in my entry.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 20 Jul 2004 19:46:40 -0400

>I think this is an unnecessary distinction. 
+1

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 20 Jul 2004 16:53:35 -0700 (PDT)

> as 'read on a certain date'. Cool thing ;)

How? I'm an aggregator author and I'm unsure how or
why I'd use this field in a feed to determine what
date the item was read [or why keeping track of this
is relevant]. 

> content to represent current information.

As pointed out the last time somebody brought this up.
Exactly what is the quantitative difference between
'fixing errors' and 'updating the content to represent
current information'? Is software supposed to
determine this programatically or is this something
the author of the piece does? Why exactly should the
date-last-typo-was-fixed and
date-lat-major-revision-was-made be treated
differently by a client consuming the feed as opposed
to processing last-modified-date? 
 
> people who need this information can have it without

What does breaking the standard mean?  

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 02:08:06 +0200

> as 'read on a certain date'. Cool thing ;)

That depends on what the format of the element is, eventually.

> Created != Issued, but for many applications this would suffice.

Yes, the distinction isn't very important, but as most tools has both an  
'save' and 'publish' action, both of these actions can be time-stamped and  
saved in a database.

> But even now most CMS have the ability to mark an entry as 'Draft' resp.  
> 'Not published yet'.

Movable Type has all the proper actions but still only offer one  
user-alterable date. I really wonder why.

> So you create content, proof read and then issue it. Later you modify
> and/or update it and at some point users read it (see Display above).

Yup. This is what I think as well, and what most big CMS's does today.  
They offer an objective 'Created', 'Issued' and 'Modified'. Some also have  
'Available' fields which one can enter a timespan the article should be  
available to and from. No 'Display' date, though. Everything is objective,  
factual and reliable.

> content to represent current information.

No, not really. If you want to distinguish minor from major modifications,  
you should rather implement something like supersedes, where one entry  
supersedes another. If you want advanced functionality, you should imho  
implement somewhat advanced mechanisms too. To supersede documents with  
new versions is the common practice almost everywhere, ranging from  
official documents, hospital journals, internet standards, USENET, book  
publishing, and so on.

> people who need this information can have it without breaking the  

Supporting supersedes is really very simple. Most advanced CMS's support  
versioning already. Supporting the supersede mechanism in Atom itself, is  
100% optional for both comsumers and producers. This pace is a concrete  
proposal of a supersede mechanism, implemented with the Dublin Core  
element <relation>:

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

---

From: Tim Bray <[email-masked]>
Date: Tue, 20 Jul 2004 17:19:00 -0700

> some CMS' so they wanted a fourth date field to

I'm not sure.  The "display" date is well-understood, implemented by 
running code @ liveJournal & other places, and easily explained by the 
analogy of the travel journal - the entry for the 8th is the entry for 
the 8th, regardless of when it was created/updated.

"Issued" is a can of worms.  Asbjørn has a very specific semantic in 
mind, joined at the hip to the notion of update-by-replacement, tuned 
to the needs of a particular publishing application.  Other voices on 
this subject are less precise in what they mean, but it's pretty clear 
they mean different things. -Tim

---

From: Sascha Carlin <[email-masked]>
Date: Wed, 21 Jul 2004 02:35:41 +0200

> to processing last-modified-date? 

Because of their semantically different meaning. Fixing a typo is 
something else than updating information. I admit this discussion is 
rather a side issue, but it has got its entitlement (Sorry for my bogus 
English, is this the correct term?).

> What does breaking the standard mean?  

Doing something the standard does not allow/offer?

Creating an extension for this special use cases (where we distinct 
Modified from Updated) could be a solution, as suggested in [1]. Or we 
could use supersedes, as suggested in [2].

 From my point of view, Atom should address this problem anyway. People 
are more and more talking about the Semantic Web, and Atom is a part of 
this greater entity. If we just come up with possibilities to express 
meta information we need and use /today/, we are not going any step 
forward - and make things even harder for our descendants.

So we should keep in mind that there are use cases we /now/ don't feel 
to be important.

Just my 2 cents, kind regards and good night for today, Sascha

[1] James, [email-masked], Date: Tue, 20 Jul 2004 17:10:29 -0600
[2] Asbjorn, [email-masked], Date: Wed, 21 Jul 2004 02:08:06 +0200

Sorry, these are not yet in the archive.

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 20:47:45 -0400

Tim Bray wrote:
> mind, joined at the hip to the notion of update-by-replacement, tuned to 
> the needs of a particular publishing application.  Other voices on this 
> subject are less precise in what they mean, but it's pretty clear they 
> mean different things. -Tim

Whatever the name are to be (and yes, names are important) my take is 
that there are two "core" dates.

The first is whatever LJ, TypePad, Blogger, JournURL and undoubtably 
countless others allow the end user to directly adjust.

The second is whatever was done over a dozen times to:
   http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 02:59:22 +0200

> the 8th, regardless of when it was created/updated.

As long as we agree that the 'display' date has a close relation to the  
content (title) of the entry than the metadata (dates and such), and that  
it's not 'issued', I think it's well-understood.

> the needs of a particular publishing application.

'Issued' as 'First-Issued', and with Atom not supporting 'minor' and  
'major' modifications (without <relation> or something similar), my  
definition of 'Issued' is not joined at the hip with anything. The support  
for 'relation' as a supersede mechanism is totally orthogonal, detached  
and opt-in.

If we first define that 'atom:issued' MUST NOT change, we can define  
superseding mechanisms afterwards, if people need to distinguish minor  
 from major modifications. But Atom cannot support this by just altering  
'issued' in the entry, because that leaves 'issued' just as useless, or  
even more so, as it would be if it was a random user-entered date.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 20 Jul 2004 17:53:54 -0700 (PDT)

> the 8th, regardless of when it was created/updated.

No, it is not. Sam described the display date as a
date that can mean be some arbitrary value not just an
RFC 822 or ISO 8601 date. I haven't seen many tools
that allow you to enter '3 months from my birthday' as
a valid date. 

> they mean different things. 

I don't see why one person's narrow focus on how one
particular tool implements one particular term should
bog down the discussion. 

issued == publication date

In blog tools today, there is no formal notion of a
publication date. In CMSs used by big media there is a
notion of a formal publication date. 

This is a fundamental dichotomy but I don't think the
answer is to try and serve 2 masters by creating three
or four date elements of which only 2 will be of use
to any particular tool. I vote for merging the notion
of user entered publication date & issued date. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Tue, 20 Jul 2004 21:16:22 -0400

> that allow you to enter '3 months from my birthday' as

I thought I had already cleared that up[1].

In any case, can we agree that the date that is "well-understood, 
implemented by running code @ liveJournal & other places, and easily 
explained by the analogy of the travel journal" is both "core" and 
should be expressed by some profile of ISO 8601?

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07098.html

---

From: Graham <[email-masked]>
Date: Tue, 20 Jul 2004 21:51:33 -0400

>> Only the two first should be required.

What do you use modified for Dare?

Graham

---

From: Eric Scheid <[email-masked]>
Date: Wed, 21 Jul 2004 12:46:31 +1000

+1

In the same sense that an entry has an "official title", they can also have
an "official date" ... which is orthogonal to the date it was created,
modified, updated, published, retrieved, etc etc. That is, a date which is
*part* of the content, and not an artefact of the circumstances of
publication.

e.

---

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

> even more so, as it would be if it was a random user-entered date.

Asbjørn: You can keep saying it, but it won't change the reality that every
syndicated blog on the Web is using just such a date every day. Here are the
bullet points:

(1) The apps that form the basis of Atom's existence produce a date that is
generally referred to as "published date" or "pubdate". This is the
all-important date that defines how entries are sorted by default.

(2) This date can and will change. It sometimes be changed by a machine,
sometimes by a user. There is no reason for Atom to overstep itself and try
to mandate the origin of the change... it is enough to expect it.

(3) This date can be expressed in as 8601 by virtually all tools. One
significant exception can produce the date, but without a timezone. That
exception has a million users and cannot be overlooked.

(4) What we call that date ("issued", "published", "Frances McDormand") is a
side-issue. It is the only date that Atom *must* support on a practical
level. If this definition conflicts with dc:issued and people actually care,
then by all means, another name should be picked out of a hat.

(5) For Atom to differentiate itself from RSS, it must support one other
date: modified. This is the one that aggregator authors are most interested
in, and most (if not all) tools can produce it.

(6) This date can and will change. The change will usually be made by a
machine, but might be user-defined in certain edge-casey scenarios. There's
no reason for Atom to overstep itself and try to mandate the origin of the
change... it is enough to expect it.

Everything else is probably better left for an extension.

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

---

From: "Roger B." <[email-masked]>
Date: Tue, 20 Jul 2004 23:44:53 -0500

> I vote for merging the notion

Dare: +1

--
Roger Benningfield

---

From: Graham <[email-masked]>
Date: Wed, 21 Jul 2004 00:43:20 -0400

> in, and most (if not all) tools can produce it.

i) For feeds produced from, say, the result of an SQL query, it's very 
hard to offer a sensible value for modified. I don't want it to 
mandatory unless tools at the consuming end need it to be.
ii) As an aggregator author, I've never wanted it. Can you fill me in 
on why others do?

Graham

---

From: "Roger B." <[email-masked]>
Date: Wed, 21 Jul 2004 00:13:46 -0500

> ii) As an aggregator author, I've never wanted it. Can you fill me in

Graham: Personally, I don't need it either. JournURL's (admittedly
simplistic) internal aggregator only needs Ye Olde PubDate, so modified
isn't something I'd use myself. If it ended up optional, I wouldn't mind at
all. 

But in desktop aggregators that mark items unread or bump them to the top
upon modification, I've seen folks voice frustration at the way RSS forces
them to use content hashes to track changes... as more and more people add
dynamic advertising to their feeds, such developers need a clean mechanism
for alerting the user when the same old item contains something additional
beyond a banner ad.

(Of course, some unscrupulous advertisers will just set modified to Now()
and abuse the system, but I suppose that's the beauty of syndication... it's
easy to unsubscribe from the unscrupulous.)

---

From: Sam Ruby <[email-masked]>
Date: Wed, 21 Jul 2004 05:46:14 -0400

> all-important date that defines how entries are sorted by default.

LiveJournal calls is a "post date"
TypePad calls it a "post's date stamp"
Blogger calls it as "date/time of my post"

> in, and most (if not all) tools can produce it.

RSS 0.91 has no item level date element.

Commonly used in RSS 1.0 is dc:date.

RSS 0.93 introduced pubDate as "indicating when the item will become 
available."

RSS 2.0 defined pubDate as "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."

My read is that the the spec definition of pubDate is most closely 
aligned with the dublin core concept of Available.  Common usage of this 
element may vary from this definition.  In particular, as a number of 
aggregators use this element to determine either sort order or even 
simply "freshness", users are prone to use this element as a proxy for 
"significantly modified" or "reissued".

A goal of Atom is to be cleanly and thoroughly specified.  If different 
people use the single date in multiple ways, these ways need to be 
differentiated.

Different aggregators may chose to ignore one or more of the dates 
provided.  But even those that do ignore one of the dates benefit by 
distinguishing these two use cases.

- Sam Ruby

---

From: David Powell <[email-masked]>
Date: Wed, 21 Jul 2004 12:11:30 +0100

> and bogus additional date.

The display date is no more bogus and fictitious than atom:title or
atom:author are bogus and fictitious.

It allows a publisher to associate a date with an entry. This date is
more like a subtitle, than any of the other dates, which are records
of the publishing process. If you want to display a date, then this is
the MOST accurate date to display.

Not every publisher would be interested in supplying a display date,
so it should not be mandatory, but it should be part of the
specification. If it is left out then it just encourages people to
abuse the other fields, which have a very different meaning.

If this date is present, then it must be machine readable. I would
hope that it would contain the local timezone of the poster, but it
might be appropriate to also allow Unqualified Local Time to be used
for this field if the timezone is not available? (I'm not sure about
this).

I expect that the other process-related date fields would contain
times in UTC, or a timezone that doesn't necessarily represent the
user, this is another reason that the display date would be the most
accurate date for display.

I am not particularly bothered about atom:issued, but other people
are, especially those involved with more formal publishing processes.
But I think that removing it would reduce the value of the date fields
for everyone. I don't think that atom:issued should be mandatory
either - it is less significant to informal publishers.

-- 
Dave

---

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

> for alerting the user when the same old item contains something 

I haven't seen many feeds with adverts in, but I have seen lots where 
people constantly meddle with wording and punctuation, which <modified> 
isn't going to solve. The <updated> element discussed by Sam a few days 
ago seems much more appropriate.

Graham

---

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

> mandatory unless tools at the consuming end need it to be.

Uhm. Huh? How did the data get itself into the SQL server in the first  
place? By themself? If not, why couldn't the tool putting it there, say  
when it did?

> ii) As an aggregator author, I've never wanted it. Can you fill me in

To signify (by e.g. marking an entry in bold) that an entry has been  
modified. How great the modification is, is out of scope for 'modified',  
though.

---

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

On Tue, 20 Jul 2004 21:56:21 -0500, Roger B. <[email-masked]>  
wrote:

> Asbjørn: You can keep saying it, but it won't change the reality that  
> every syndicated blog on the Web is using just such a date every day.

Is it so that Atom should be modeled solely after current practice? If so,  
why do we bother to define anything but a vague 'date' for entries, and  
why bother specifying what goes in <title> and <content>? If current  
practice is so good, and shouldn't change, Atom == RSS.

I thought that part of the point with Atom was to define a better  
specification, a better model and a better practice than the current state  
of affairs.If you disagree in this, please say so.

> (1) The apps that form the basis of Atom's existence

Why does this matter? Atom is young. Heck, RSS is even young. We can  
define a strict set of dates and clearly specify what they should be, and  
I actually believe most tool providers will support this eventually. Okay,  
old entries will have bad dates, but at least new ones will have good  
ones. That's better than having bad dates on both old and new entries,  
imho.

> produce a date that is generally referred to as "published date" or
> "pubdate".

Movable Type's date is initially 'created' (it gets set the first time you  
change the entry), but can be updated by the user to be anything.

> This is the all-important date that defines how entries are sorted by
> default.

If the prime goal of dates was sorting, RSS wouldn't have an RFC-822 date.

> (2) This date can and will change.

The current vague date will, of course. But the dates in Atom should be  
treated as Atom defines. Why shouldn't Atom define anything that somewhat  
breaks current practice?

> It sometimes be changed by a machine, sometimes by a user.

What's the use case for randomly changing a date?

> There is no reason for Atom to overstep itself and try to mandate
> the origin of the change.

Change whatever you like, but not 'issued'. Not 'created' either.  
'Display' and 'modified' can be modified all you want, though.

> exception has a million users and cannot be overlooked.

That exception is afaik agreed to be a bad practice, and it has been  
proposed several solutions to it. Atom should not cater it, at least.

> (4) What we call that date ("issued", "published", "Frances McDormand")  
> is a side-issue.

Yes, I don't care what it's called as long as it gives me «the date the  
entry was (first) published to its intended audience». If people want  
re-issuance mechanisms, 'issued' is not the date to hack on.

> It is the only date that Atom *must* support on a practical level.

If the date can be just about anything, I don't understand why having it  
at all is useful. What will you do with it, if you don't know if it's  
«first-issued», «last-issued», «when the author thought the entry was  
going to be issued» or «when the author was going to issue the entry»?

> If this definition conflicts with dc:issued and people actually care,

The point, and problem, is not what it's called. The problem is partly the  
current practice and that the date is of great importance in any  
publishing process. Current practice shoots a big hole in the publishing  
process bubble, at least if we model Atom after it. Why would we ever  
choose to model Atom after an imho bad practice, when century old  
publishing processes have proven to work for all mediums?

> date: modified. This is the one that aggregator authors are most  
> interested in, and most (if not all) tools can produce it.

Absolutely all tools can produce 'issued' as well. If not, they are not  
capable of publishing the entry onto the web. And if they're not, I  
wouldn't put much money on them being used at all.

> machine, but might be user-defined in certain edge-casey scenarios.

What edge-cases are these, exactly? Are they based on current practice  
(where only one date is available)? Why are these practices something Atom  
should cater and be modeled after?