In the past I have questioned the use of ISO8601 as opposed to W3CDTF.
I understand ISO8601 is being proposed in DC CD AP to allow date ranges
to be specified, whereas I have always just used W3CDTF for date ranges
based on old DC-Arch discussions [1].  This of course is a question
DC-Date aims to resolve once-and-for-all, except that the WG appears to
have stalled...

DC-Lib AP also includes an ISO8601 encoding scheme, but they are
specifically after other ISO8601 functionality such as BCE dates,
non-hyphenated date formats, etc.  I feel more comfortable with DC-Lib's
use, but less with ours (using it just to allow slashes for date
ranges).  ISO 8601 is an extremely complicated encoding scheme to handle
- I fear what will turn up in DC-Lib data (I would prefer DC-Date came
up with a new profile of ISO8601 so we don't have to deal with
_everything_ in ISO 8601).

But back to DC CD AP - It doesn't feel right to be re-defining an
encoding scheme as we have done in the current draft - either you are
using ISO 8601 or you're not!  A side issue is using the "dcterms"
namespace is anticipating DCMI will endorse it.

I think we should propose DC-Date make their top priority decision be:
"Does the W3CDTF encoding scheme include date ranges, and what types are
included (eg. open ended)?".  [NB: I will be pushing strongly on DC-Date
that it _does_ include ranges.]  This is probably the longest-standing
issue around W3CDTF dates, and potentially could be resolved reasonably
quickly.

Then we could remove the dcterms:ISO8601 encoding scheme (and I could
sleep at nights ;-) ).

A small extra note - the AP summary document omits W3CDTF from
dcterms:created and cld:dateContentsCreated.

Thanx,
Douglas

[1]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402&L=dc-collections&P=R572&D=0&I=-1&T=0