Draft for review: ISO 8601 date work on IS 29500

[Chris Rae]

Hi Rick - we do need to resort to xs:String, because the cell value can also actually be a string. I wasn't very clear at the beginning of this thread, but the cell type is denoted by its v attribute, which can be one of:

b (Boolean): Cell containing a boolean.
d (Date): Cell contains a date in the ISO 8601 format.
e (Error): Cell containing an error.
inlineStr (Inline String): Cell containing an (inline) rich string
n (Number): Cell containing a number.
s (Shared String): Cell containing a shared string.
str (String): Cell containing a formula string.

The actual content is in the v attribute, which is xs:String in the schema, with the restrictions in the prose. Unless we break back compatibility with applications which use IS 29500:1, we'll have to keep this somewhat schema-unfriendly link between these attributes. If I follow it right, adding the MustUnderstand namespace (a-la ODF) would cause any files with the new narrower-scope date formats to be unreadable in applications which were only compliant with IS 29500:1 - I'd be less keen to do that given that the changes Gareth and I are making here are only reductive, so that application would have been able to understand these files fine if we left the markup structure the same and just tightened down the date values we could accept in there.

Chris

-----Original Message-----
From: rjelliffe at allette.com.au [mailto:rjelliffe at allette.com.au] 
Sent: 12 July 2010 22:34
To: e-SC34-WG4 at ecma-international.org
Subject: RE: Draft for review: ISO 8601 date work on IS 29500

> 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