> From: C. M. Sperberg-McQueen
> Sent: Tuesday, January 11, 2011 1:14 PM
> Implicitly, the document seems to take for granted that information in
> all of these forms should be representable in what XSD refers to as a
> simple type. But why?
Here is some additional (unpublished) historical background.
We've maintained a number of xml schemas here,
MODS http://www.loc.gov/standards/mods/mods.xsd
MADS http://www.loc.gov/standards/mads/mads.xsd
METS http://www.loc.gov/standards/mets/mets.xsd
PREMIS http://www.loc.gov/standards/premis/premis.xsd
and others, going on ten years now, and the community that uses these
schemas has all along had interest in an enhanced datatype that incorporates
these edtf features, but it was the PREMIS effort (the last of those listed)
that was the catalyst for the edtf initiative.
If you look at that schema, near the bottom you will see an edtfSimpleType
that defines several regular expressions incorporating several of these
features and combines them with xs:date and xs:dateTime into an enhanced
simpleType for use in validating PREMIS data. (Note these are way out of
date, the PREMIS schema has not kept up with the changes in the edtf draft.)
So any normal date or dateTime will validate, but only very rudimentary
validation works for any of the enhanced features (e.g. you can't validate
that the month is less than 12, or that if the month is November the day is
30 or less, etc.) because the regular expressions can ony do so much without
becoming unbearably complex.
I suppose the point is, we are hoping that if this datatype becomes accepted
as a standard, then those who implement software that already validates xs
types will simply add support for these edtf features to that software. (As
opposed to trying to do it via regular expressions which is not a good
approach.)
--Ray
|