Subject: PaceDateOfSubject

From: Eric Scheid <[email-masked]>
Date: Fri, 08 Oct 2004 03:15:20 +1000

Abstract

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.

http://www.intertwingly.net/wiki/pie/PaceDateOfSubject

(it's kinda long, so I won't post it all here)

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 07 Oct 2004 20:30:58 +0200

>http://www.intertwingly.net/wiki/pie/PaceDateOfSubject

Our charter states

[...]
  it is expected that all but the most basic, generic metadata and
  functions will be accommodated through extensions, rather than in
  the core documents.
[...]

Yet much of the rationale seems to disagree with our charter, there are
arguments like if this is added there is no need for extensions (which
is true for any meta data) and it is said that publishers will be forced
to hijack some other meta data mechanism for this purpose (which seems
again true for any meta data not in the core documents). Maybe such
arguments can be replaced by a more convincing argument why this meta
data in particular is most basic, generic metadata or at least very
close to that?

I am opposed to this Pace as it is not sufficiently generic; it does not
allow me to associate 08 November 2004 to an entry, I rather have to use
08 November 2004 07:00:00 UTC which means I would have to make some time
up just to use it which further means that localizing the date to local
time zones might yield in false information, a reader in some distant
time zone might read the data as 07 November 2004 which would be bad for
the birthday use case, for example. The lack of date ranges, for which
there is no rationale in the Pace, has all the negative side effects the
Pace cites as rationale for the element in general,

[...]
  Doesn't mean someone couldn't write an entry titled "Start of Six
  Day War" and put the starting date into subject-date.
[...]

"hijacks" the atom:title element to encode additional meta data which
the Pace considers a bad idea. I would not want to munge atom:title
elements that way just to circumvent shortcomings of the element.

A typical use case for such information in "event feeds" would be
exporting such information into some calendar or schedule application,
such functionality would however depend that users can use it in a
convenient manner and beeing asked about time zones and having to modify
the imported entries to cover the actual duration of the event would
likely be annoying.

I would support constructs with similar semantics that allow for less
specific dates (or rather, actual dates not date+time combinations) and
ranges of dates and/or date+time combinations to cover complete events.