A supplementary page to PaceEntryDates (NB the examples on this page aren't based on the proposal and do not illustrate its usage).
Describe ways you think <issued>, <modified>, and <created> could be used, either at the publishing end, or the aggregation end.
I run a small-town newspaper, The Hypothetical Times, published on Wednesday and Saturday. Because our printer is in another town, I usually put the paper to bed at around 2pm the day before, though if worst comes to worst I can email in changes up to around 6pm that night. Generally, things with a created date before 2pm Tuesday have an issued date of Wednesday, but sometimes a later created date is still Wednesday, and sometimes something gets pushed out of Wednesdays paper despite being created before 2pm Tuesday.
I have two syndication feeds, one free one which gets updated in the wee hours of Wednesday and Saturday, and one for subscribers only, which gets updated as soon as I've finished editing a story. That one is wildly popular, particularly the police log and the obits, because our population is approximately half retired people, and half juvenile delinquents and meth cooker-dealers.
In my subscription feed, I need the creation date, which is the date that I publish an item to the feed, because that's how aggregators organize things, and I need the issued date, which is the date of the dead-tree paper you need to get extra copies of to send to the grandkids, and I need the modified date, which is the date when I discover that I got the name wrong, and it wasn't really the mayor's son.
In my free feed, I need the issued date, not just the created date, because I have partners who syndicate my headlines, trying to help me sell more papers, and they need to know which stories are in the current issue of the paper, which isn't just a straight "if creation date was less than 2pm Tuesday, it's in Wednesday's paper". I don't entirely need the creation date, but I like having it, so that people who aren't using my subscription feed can see that I actually wrote about that story two days before, and if they subscribed they would have known about the good gossip then.
I run a blog that covers the "news" in a WWII strategy game that I play with some friends. Because we all use good Atom-aware aggregators, which realize that issued is a "display date", while created and modified are metadata that can be useful for display, but are mostly useful for sorting and filtering, I can publish my items with the issued date being the date of the events in the game, e.g. December 7th, 1942, and our aggregators will use that for display, while sorting items by the created date, and letting us choose to sort by the modified date (and using modified != created as a trigger to offer to show diffs).
I run a normal, ordinary blog, which I update whenever I choose, and sometimes modify when I got something wrong. I create drafts, and don't publish them for weeks, and as far as I'm concerned, that's nobody's business but mine. I set my created and issued dates to exactly the same thing, the date I make an entry public, and I don't worry about doing it twice because it's just code in my template, and I know it's useful for other people in other situations.
[AsbjornUlsberg] What's this?
A publisher syndicates weather forecasts which they get from a third party. They receive periodical updates if conditions change, and receive the same forecast marked "no change" if no changes. They publish them in a feed on an hourly basis ("this is the 6 o'clock news"). It is useful and interesting to see that the forecast which was made and published at 6am has been re-issued at 10am with no changes, as this is better than only having the 6am forecast and not knowing if it has or has not changed. It is best if subsequent re-issues don't trigger "hey look, it's modified!" semantics if the forecast hasn't in fact changed. It is best if multiple forecasts for the same day were not issued, in case superceded forecasts are not dropped out of the reader's aggregator. Sometimes the boys in the weather office get busy and are unable to issue a "no changes to forecast" forecast, and so the publisher uses the issued datetime of the last notice in the next publishing (ie. issued stays stuck on the last datetime).
<created> is the datetime of the first forecast. It might not be the datetime of when it was "first published onto the internet", because this publisher only updates their feed on an hourly basis. In subsequent republishings it does not change.
<issued> is the datetime it was published, or republished as a confirmation of no-changes. Throughout the day it would change.
<modified> is the datetime the forecast was modified. It would only change if the forecast itself has materially changed.
I run a small magazine, Hypothetical Illustrated, which publishes stories each month in it's print edition, but also publishes them on it's web site two weeks after the print edition hits the streets. Date created would indicate the publication date of the print magazine, while date issued would indicate when the story was posted to the web site. Date modified would be used when corrections to the story are needed, and appear on the web site.
I work in one of Norway's largest news corporations, and when a news is created in the CMS, it get's a created date set in the database. Then, the article is saved several times, during its flow of editing; adding pictures, hyperlinks, headings, an ingress, etc. Each save operation updates the modified date in the database.
When the article is finished, it is published and made publicly available on the NRK.no website. This operation gives the article an issued date, which will never change. When the article is opened for editing at a later point in time, created and issued are untouched, while modified gets updated each time the journalist saves it. When the changes are done, it is published again to make the changes publicly visible, but issued remains the same.