Subject: PaceDateAntoneRoundy2 created

From: Antone Roundy <[email-masked]>
Date: Thu, 12 Aug 2004 19:13:19 -0600

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

Based on the last few days' discussion, I've created one final 
proposal, after which I will almost surely be silent on this issue.  
PaceDateAntoneRoundy2 defines two Date Constructs, neither of which 
duplicates anything defined by dcterms.  One of the two is required, 
and publishers are strongly encouraged to supply the more "objective" 
of the two.  Publishers are encouraged to use dcterms dates for any 
additional time stamps they wish to express.

---

From: "Roger B." <[email-masked]>
Date: Fri, 13 Aug 2004 06:44:31 -0500

Antone: It meets my absolute needs in both my roles, and the descriptions of
the elements are different enough that I think we'd be relatively safe from
confusing template-tweaking users.

I still prefer PDSamRuby for its simplicity, but you're getting very close
to that. If it would help with consensus, I would strongly consider giving
this a +1.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: "Andreas Sewe" <[email-masked]>
Date: Fri, 13 Aug 2004 19:50:46 +0200

Almost the only part I somewhat dislike is that the pace unnessecarily
requires the use of UTC for atom:c.

Quoting <http://www.intertwingly.net/wiki/pie/PaceDateAntoneRoundy2>:
> atom:c MUST be expressed in UTC. Thus, it MUST include one of the following
> time zone designators: "+00:00", "-00:00" or "Z"."

Why not allow any timezones, as long as one is present? Converting dates to
different timezones is easy enough, and I bet a lot of informational dates
added using DCTerms will use other time zones than UTC, too.

Regards,

Andreas Sewe

---

From: "Andreas Sewe" <[email-masked]>
Date: Fri, 13 Aug 2004 20:00:12 +0200

Antone Roundy wrote:
> of the two.

Basically I like the pace quite a lot. It seems to contradict itself though:

Neither
> atom:entry elements SHOULD contain an atom:c element, but MUST NOT contain
> more than one.
nor
> atom:entry elements MAY contain an atom:d element, but MUST NOT contain more
> than one.

requires the presence of a date construct. So is the text of the abstract
("One of the two is required, and publishers are strongly encouraged to supply
the more "objective" of the two) intended to be normative, or should the
SHOULD be a MUST instead? Personally I prefer the latter interpretation.

Antone, can please you clarify this issue? Thanks.

Andreas Sewe

---

From: Antone Roundy <[email-masked]>
Date: Fri, 13 Aug 2004 12:17:35 -0600

> SHOULD be a MUST instead? Personally I prefer the latter 
The normative text is "Each atom:entry MUST contain one or more of the 
following Date Constructs." in section 5.6.  But (primarily) because 
some systems will not be able to provide atom:c, it is a SHOULD instead 
of a MUST.  Perhaps the final spec text could be more explicit about 
saying that the worst case is that a date of unknown significance to 
the entry gets put into atom:d.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 13 Aug 2004 12:23:04 -0600

> added using DCTerms will use other time zones than UTC, too.
During previous discussion, some have expressed the desire to have 
dates constrained to UTC to enable simple string sorting rather than 
having to parse dates.  Note that the date construct that is intended 
to take more of a display date type role is NOT constrained to any 
particular time zone.  If it is decided that we don't want to constrain 
the time zones of any of the dates, that's fine with me.