Define a Date Construct to hold a publisher-selected date which is the date of the subject of the entry. This date is not tied to an event in the publishing process.

While inspired in part by PaceDateSubjective, this pace has been more refined, and the definition and use-case semantics narrowed.





(see also the References section below)


Insert the following after section 5.6 "atom:updated" Element (draft-ietf-atompub-format-02.txt)

        === 5.x "atom:subject-date" Element ===

        The "atom:subject-date" element is a Date Construct indicating
        the date and time of the subject of the entry. It is not directly 
        related to events in the publishing process.

        For example, atom:subject-date might be used to express the date
        which a journal entry describes, although that entry might have
        been written at a later date. Other example uses of this element
          * web publication of a diary from the past (eg: Pepys' Diary)
          * a weather feed, where each entry is specific to a given day
          * entries in a feed of upcoming birthdays
          * a series of essays regarding significant dates
          * a feed of 'on this day' notes & trivia
          * a retrospective timeline for a given subject
          * a simple list of upcoming events at some venue
          * a feed of deadlines or other event dates for a project

        atom:entry elements MAY contain an atom:subject-date element but
        MUST NOT contain more than one. The content of this element MUST
        conform to the Date and Time format defined in RFC 3339.


If there is no subjective date element, then publishers will be forced to hijack some other date field for their purposes (eg. date-updated). Thus, date-subject is a good escape valve, protecting the objective date fields (particularly date-published, which has been strongly argued for no-changes-ever).


Here are some snippets from discussion of PaceDateSubjective, a predecessor to PaceDateOfSubject. PaceDateSubjective was criticised as being vague and ambiguous, with bad example uses. This pace hopefully corrects those shortcomings...


rejected names for this element include:

date ranges are not covered by this pace (yet - suggestions welcome)

Doesn't mean someone couldn't write an entry about the start of Six Day War and put the starting date into subject-date. If however someone wants to write about this particular six day date range in 1967 then the use of subject-date would be inappropriate.

We explicitly disallow the model of {0,*} instances of atom:subject-date in atom:entry because the theoretical utility is undermined by the practical difficulty of coding support for the elements under that semantic.