Abstract
This Pace specifies a single dateline element which gives the date and place of origin for an Atom entry.
Status
Open, Incomplete
Rationale
There is evident confusion on the existing dates; this will inevitably lead to interoperability issues. It also makes sense to optimize for the most common use case where the entries are created, issued and make available simultaneously and never modified.
Proposal
Remove sections 5.6 "atom:modified", 5.7 "atom:issued", and 5.8 "atom:created" Element.
Insert the following as a new section in their place:
-
The "atom:dateline" element is a Date construct that indicates the date and place of origin for a weblog entry. atom:entry elements MUST contain an atom:dateline element, but MUST NOT contain more than one.
Unless the following elements are also present from the dcterms namespace, this value is to be presumed as the the date that the entry was created, valid, available, issued, modified, accepted, copyrighted, and submitted. In other words, these values MUST be present if they differ from the value of atom:dateline. The value of the various dcterms dates MAY be empty, and if so, and the presense of such values is meant to be interpreted as unknown.
Informative note: many consumers depend on a notion of when the entry as last made available to indicate a sense of "freshness".
Impacts
This proposal removes the existing dates, and defines a new one.
Example
<entry xmlns="" xmlns:dcterms="http://purl.org/dc/terms/"> <title>PaceDateline</title> <link href="http://www.intertwingly.net/wiki/pie/PaceDateline"/> <id>http://www.intertwingly.net/wiki/pie/PaceDateline</id> <dateline>2004-07-24T10:29:52-04:00</dateline> <dcterms:valid/> <dcterms:modified>2004-07-25T16:04:00-00:00</dcterms:modified> </entry>
Notes
At this time, the syntax for providing location information has not been fleshed out. A brief scan of prior art turned up Semantic Web Developer Map: representing locations of people, research groups and projects. I must admit that I do find the notion of naming the three letter code of one's nearest airport as an intriguing idea - being both compact, readily available, and suitable for searches and comparison. Imagine feedster searches for the week of 2004 July 26 in BOS and PDX.
If the WG decides not to provide a means for capturing the place of origin, then a different element name should be chosen.
The presumption is that atom:dateline will be defined as a profile of ISO 8601, probably one that is compatible with both W3CDTF and RFC 3339. An issue to be worked is the need for support and/or guidance on how to represent dates for which the local time zone offset is not known.
A decision will need to be made as to whether or not this element also replaces the feed level atom:modified element.