Draft for review: ISO 8601 date work on IS 29500

[rjelliffe at allette.com.au]

> I realise I'm splitting this thread somewhat, but just to clarify Gareth
> and Rick's discussion here - Rick, are you thinking we could use a union
> type of (first) string, then (second) xsd:ourRestrictedDateTime?

Probably union of first an xsd:dateTime restriction, then second an
integer in the appropriate range. There should be no need to resort to
xs:String.

[I have an alternative suggestion, which I am sending in a separate email.]

> If so, we
> do still have something of a problem because a document containing cell
> type t=d and a valid string inside the v attribute will schema-validate
> fine, but will not actually be valid according to the prose because in
> that instance the value must be an ourRestrictedDateTime. I'd agree that
> this is better than nothing, but I do wonder whether it just adds some
> complexity to the schema that isn't helping too much?

I think Chris brings up a good point about completeness: is a schema still
useful when it is somehow incomplete?

XML Schema 1.0 perhaps encouraged an attitude that the purpose of a schema
is to unambiguously assign a type to each element (or attribute) name. It
could not cope with real-life idioms such as using a type selector based
on an attribute value: XSD 1.1, RELAX NG and Schematron can, of course.
But the inexpressiveness of a particular schema language is no reason not
to model things as best as possible.

A schema is almost always a coarse sieve: Goldfarb used to say that the
"content model" was called a 'model' for that reason.

(My prejudices are that a markup standard should be as objective and
verifiable as possible, and that this directly means that schemas and
other simple executable notations should be used in preference to natural
language wherever possible. Schemas should not be seen as window dressing.
In this case, if XSD 1.0 is not powerful enough, then it should be used as
far as it will go, and other constraints expressed in Schematron. )

Validating dates in schemas where there has been some messiness would seem
exactly where you *would* want as tight a schema as possible, I would have
thought.

For a standard schema, the schema also needs to act as a way to tie the
constraints of elements into the mainstream ecosystems: to say "This is
our home-made version of ISO8601" is exactly what a developer does not
want to see: they want to know "Well, how does it fit in XML Schemas
simple types (which have widespread library support)? How does it fit in
with regular expressions (which have widepread library support)?"


Cheers
Rick Jelliffe