Subject: Alternative to the date regex

From: Graham <[email-masked]>
Date: Fri, 25 Mar 2005 17:11:09 +0000

Currently we have this

    "A Date construct is an element whose content MUST conform to the
    date-time BNF rule in [RFC3339].  I.e., the content of this element
    matches this regular expression:

    [0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)
         ?(Z|[\+\-][0-9]{2}:[0-9]{2})

    As a result, the date values conform to the following 
specifications..."

The problem with the regex is that it's entirely redundant. If we look 
at Norm's message where the regex was suggested [1], he intends it as a 
profile of xsd:dateTime, which allows a variety of date formats. 
However we're using it as a profile of RFC3339, which already requires 
that date-times match the regex 100%. Having the regex there as well is 
just confusing - until preparing this email I was under the impression 
it made some additional restrictions on RFC3339.

The nearest thing I see to an additional restriction is that there must 
be a capital T between the date and time, which the date-time BNF rule 
we mention also requires, but the prose later mentions you might be 
allowed to use something different.

Proposal:
Replace the first para and regex with:

    A Date construct is an element whose content MUST conform to the
    date-time BNF rule in [RFC3339]. Note this requires an uppercase 
letter T
    between the date and time sections.

Secondly, *all* RFC3339 date-times are compatible with the 4 specs 
mentioned, so the wording of the second paragraph ("As a result...") is 
a bit strange, since it's not as a result of anything we've done. Just 
say "Date values expressed in this way are also compatible with...".

Graham

[1]http://www.imc.org/atom-syntax/mail-archive/msg13116.html

---

From: Robert Sayre <[email-masked]>
Date: Fri, 25 Mar 2005 12:21:43 -0500

Sounds like a plan to me. +1.

Robert Sayre

Graham wrote:
>    As a result, the date values conform to the following specifications..."
> 
> profile of xsd:dateTime, which allows a variety of date formats. However 
> we're using it as a profile of RFC3339, which already requires that 
> date-times match the regex 100%. Having the regex there as well is just 
> confusing - until preparing this email I was under the impression it 
> made some additional restrictions on RFC3339.
>

---

From: Walter Underwood <[email-masked]>
Date: Fri, 25 Mar 2005 10:10:45 -0800

+1 on dropping the regex. It isn't from any of the other specs,
it isn't specifically called out as explanatory and non-normative,
and it is too long to be clear.

Some examples would be nice, along with some examples of things
which do not conform.

wunder

--On March 25, 2005 5:11:09 PM +0000 Graham <[email-masked]> wrote:

> The problem with the regex is that it's entirely redundant. If we look at Norm's message where the regex was suggested [1], he intends it as a profile of xsd:dateTime, which allows a variety of date formats. However we're using it as a profile of RFC3339, which already requires that date-times match the regex 100%. Having the regex there as well is just confusing - until preparing this email I was under the impression it made some additional restrictions on RFC3339.
> 
> The nearest thing I see to an additional restriction is that there must be a capital T between the date and time, which the date-time BNF rule we mention also requires, but the prose later mentions you might be allowed to use something different.
> 
> Proposal:
>     date-time BNF rule in [RFC3339]. Note this requires an uppercase letter T
> Secondly, *all* RFC3339 date-times are compatible with the 4 specs mentioned, so the wording of the second paragraph ("As a result...") is a bit strange, since it's not as a result of anything we've done. Just say "Date values expressed in this way are also compatible with...".
> 
> Graham
> 

--
Walter Underwood
Principal Architect, Verity