Closed tcatapano closed 9 years ago
@tcatapano Almost there. My tests of @normal
work in the following patterns: YYYY, YYYY-MM, YYYY-MM-DD, YYYY/YYYY, YYYY-MM/YYYY-MM, and YYYY-MM-DD/YYYY-MM-DD. The schematron validation throws an error, however, when the begin and end of a range do not have the same pattern. For example, YYYY/YYYY-MM, YYYY-MM-DD/YYYY-MM give errors. I see from your commit that this was intentional on your part.
Am I mistaken that 8601 allows different formats in either side of the range? I believe it was legal in the schema version of EAD2002. We should defer to that precedent if there is any ambiguity.
And the range is only an issue in @normal
. Ranges are not permitted in @standarddate
, @notbefore
and @notafter
.
You are getting the current behavior of the code. Part of this issue is that a clearer definition of what we mean by "ISO 8601" date needs to be articulated. ISO 8601 allows for a lot of variation which is difficult to test for. What we really doing is testing against a subset of ISO 8601; and different ones for normal and the other date attributes. The pattern is the one used by the EAD 2002 XSD and RNG schemas. It will permit these patterns:
YYYY YYYYMM YYYY-MM YYYYMMDD YYYY-MM-DD
For normal, each of these may be followed with a "/" followed by one of these patterns.
Note that the latest date in the pattern is 2999, Dec 2999, and December 31, 2999. Also, the pattern permits incorrect dates such as April 31 and non leap year Feb 29s, as well as the years 0000 and -0000.
@tcatapano Looks good. But to be clear, I'm seeing validation of single dates and ranges with YYYY, YYYY-MM and YYYY-MM-DD. I'm not seeing YYYYMM or YYYYMMDD validate. That's what was permitted in the EAD2002 schema, so let's stick with it.
Noticed the same thing. Yes, let's leave it. Closing.
to allow for "1999/2001" "1999-01-05/1999-01-15", etc...