I think some common terminology would be helpful, here.
I am going to use the term "regularize" to mean something like "to
change syntactically so that all occurrences are the same", and
"normalize" to mean something like "to change so that it matches an
external standard system".
Thus "3 1/2 inches" might be regularized to "3.5 in", and might be
normalized to "8.9 cm".
In P4, the value= attribute of <date> is ambiguous -- it can be used
for either regularization or normalization. If it is being used to
normalize to some standard other than (proleptic) Gregorian, this
should be documented in the <stdVals> element in the TEI header. Note
that it is not 100% explicit, but it is my belief, that the value of
calendar= applies to the *content* of <date>, but not necessarily to
the value of the value= attribute of <date>.
This is almost exactly the "madness" that Sebastian refers to:
SR> In theory one could declare up front "all my normalized dates are
SR> in Klingon notation", and leave the datatype of @value as just
SR> character dat[a]. But this seems like madness.
Personally, I would hardly characterize the P4 approach as "madness",
but certainly a good number of us have complained that the value=
attribute of P4 was inadequately constrained, and perhaps too loosely
SR> It seems to me quite clear that we should leave "@value" as
SR> meaning "@isovalue" (we could even rename it),
P5 does *not* use ISO dates! At your insistence, Sebastian, we use
W3C dates instead. (With the exception that times that are not
precise to the second are permitted, which I insisted on.)
Besides the current question of whether to insist on normalization
against the (proleptic) Gregorian calendar or not, there is also the
recently raised question of allowing use of the year 0000 and a few
other things in the ISO format that are not available in the W3C
If it were just value= of <date> and <time> I would suggest the
Three datatypes replace the current data.temporal:
data.temporal.w3c to follow the strict rules of W3C dates (no
imprecise times, no year 0, no way to express
durations or repeating intervals, etc.)
data.temporal.iso to follow the slightly less strict rules of ISO
data.temporal.non-Gregorian syntactically the same as .iso, but the
semantics do not require that the date
identified be in the (proleptic)
Two attributes replace the current value=:
norm=, the value of which is normalized to (proleptic) Gregorian;
by default the datatype would be data.temporal.w3c.
reg=, the value of which is merely a regularization of the date,
expressed in whatever calendar is indicated in <stdVals> in
the header. The default datatype would be
However, as Lou has pointed out, we also need to worry about the
attributes from the class att.datable: from=, to=, notBefore=,
Of course, from= and to= are not needed in the world of
data.temporal.iso or data.temporal.non-Gregorian, but the notBefore=
and notAfter= would still serve a useful purpose, no?
 Alright, it's really value= of att.datePart, and thus of <date>,
<time> and also of <day>, <distance>, <hour>, <minute>, <month>,
<occasion>, <offset>, <second>, <week>, and <year>.