Due to a lot of hard work and co-operative thinking, with notable contributions from Eric Scheid and Sascha Carlin, we have (I think) rough consensus on the list of dates we could possibly have in Atom. It seems unlikely that all of these can find a home in Atom. Sam Ruby also usefully pointed out that in the case that we don't get all the kinds of dates any one application needs, doing an extension should be easy since Dublin Core has lots of different dates and a handy namespace to put them in.
The goal here is to get a feeling for how many of the possibilities are likely to have enough backing to have a realistic chance of getting in.
Filling Out the Survey
Here are the kinds of dates Atom could have, in alphabetical order of name. All dates are constrained to RFC3339 syntax as closely as possible. For the purposes of this survey, please do not argue about the definitions of the dates. I have gone back and reviewed the mailing list and I'm confident that these definitions are close enough to a a largely-shared view as to be useful.
Created: the date the entry was originally created
Dateline:the date the publisher wishes visibly to assign to the entry (note RFC3339 problems on this one)
Issued: the date the entry was first made available
Modified: the most recent date on which any aspect of the entry's content changed
Updated: the most recent date on which the publisher wishes to draw attention to the entry's having changed
To help maximize the information yield, let's sort ourselves into three roles. When you fill out the survey, consider categorizing yourself
Readers: people who write software that reads syndication feeds
Publishers: people who generate Atom feeds.
Others: Other levels of interest
Here are the possible choices in the survey:
-2: I won't be able to use Atom if this is included
-1: Atom would suffer from having this included
0: I don't care.
+1: Atom would benefit from having this included
+1R: Atom would benefit from having this included, and it should be REQUIRED in every Entry
+2: I won't be able to use Atom if this isn't available
+2R: I won't be able to use Atom if this isn't available, and it should be REQUIRED in every Entry
Please Add Yourself to the Survey Below This Line
[RogerBenningfield]: That was tough, because I had to -1 some things as a Publisher that would have been better described as -1R, or "Atom would suffer from having this as a required element". While I personally think four core date elements probably amounts to two too many from a view-source POV, I'm not actually opposed to any of them as long as they're optional.
[ArveBersvendsen]: While I have answered the survey, I would like to state that I think this survey is premature and incomplete as long as we don't agree on the specific meaning of some of the dates - we really need to have consensus on "What does X mean" before we can actually form an opinion on X.
[SamRuby]: I would like my vote to be interpreted as "-1 if optional and core". Optional core elements don't promote interoperability. Update: I acknowledge comments below by GrahamParks and RogerBenningfield that clear precedence rules may mitigate this concern.
[BillDehora]: I agree with Sam: -1 if optional and core.
[SaschaCarlin]: Sam, sorry, I don't get what your vote means then
[SamRuby]: read the votes I recorded above as the ones I would make if the corresponding elements were made required and core.
[GrahamParks]: I don't think optional core elements cause problems if there are clear rules about what to do when one is missing (eg No dateline => dateline =issued). Required core elements force people to pollute fields they can't otherwise fill.
[SamRuby] Question: can this be flipped to (No issued => issued=dateline)? And if tools can't provide a stable and unchanging issued date, does defaulting issued to a one that they can provide but is mutable actually pollution?
[RogerBenningfield]: I agree with Sam and Graham simultaneously. The only out between those two extremes (a lot of OCEs that confuse people, or a lot of RCEs full of bad data) is to strip down the number of core elements to two (issued and modified) and broaden their definitions to be as widely applicable as possible. That means throwing out the subtle bits, leaving them for extensions. Something was issued at a given time, and something was modified at a given time. That's it. No other implications or qualifications.
[SamRuby] I prefer names that either don't already have strong predefined associations or have associations that match the definition we intend.
[AsbjornUlsberg]: I agree with ArveBersvendsen in his above comment.
[KenMacLeod]: I agree with SamRuby, ArveBersvendsen, and AsbjornUlsberg, this survey is seriously skewed by using "loaded" terms with lots of implicit meaning that is not captured by the "local" definitions provided with them.
[RobertSayre]: I was happy to discover I don't care about any of these. I'm think some of them are crufty, but not really damaging.
[BobWyman]: As a reader of feeds, our primary concern is to detect how the feed generator wants entries to be displayed (i.e. DateLine) and when they want to call our attention to a change (i.e. Updated). We would like to be able to detect and track *any* change but that is less important than being able to communicate the writer's intent.
[WalterUnderwood]: My "Publisher" perspective is "can I make an Atom feed from the data in our search index?" My "Reader" perspective is "is this useful to the crawler?" As a publisher, if created, issued, or modified were reqired, they would be -2 for us. The index does not have that information. I assumed that dateline is optional, because it is author-supplied.
[HenriSivonen]: The system I have implemented Atom 0.3 feeds for does not record the creation date. Of course, it is not that I could not use Atom if that was required, but I could not use it without putting some other date (issued) there.