Draft for review: ISO 8601 date work on IS 29500

[Chris Rae]

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? 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?

Gareth, as ever, correct me where I'm being bone-headed.

Chris

-----Original Message-----
From: Horton, Gareth [mailto:Gareth_Horton at datawatch.com] 
Sent: 08 July 2010 11:50
To: Chris Rae; rjelliffe at allette.com.au
Cc: e-SC34-WG4 at ecma-international.org
Subject: RE: Draft for review: ISO 8601 date work on IS 29500

Hi all,

Of course this would not be in the schemas, purely informative information for those wishing to create a type for their own purposes, which accurately describes the subset and allows tighter validation, once the data has been extracted from the catch-all bucket of the cell value element (xsd:string, as it can contain *anything*, numbers, chunks of text, dates etc) and identified.  

This identification could be from relying on the presence of the t=d on the cell, indicating that it is a date (not bulletproof since this is not and cannot be required in the schema), or by checking the cell format information.

We could also have the range set here as well, along the lines of:

<xsd:simpleType name="IS29500strict_datetime">
  <xsd:restriction base="xsd:dateTime">
     <xsd:pattern value="<other_restrictions_like_no_negative_years_and_no_hour_24_and_maximum_of_3_digits_for_fractional_seconds>.+T[^Z+-]+" />
     <xsd:maxInclusive value="9999-12-31T23:59:59.999" />
     <xsd:minInclusive value="0001-01-01T00:00:00.000" />
  </xsd:restriction>
</xsd:simpleType>

Gareth


-----Original Message-----
From: Chris Rae [mailto:Chris.Rae at microsoft.com]
Sent: 08 July 2010 19:16
To: rjelliffe at allette.com.au
Cc: e-SC34-WG4 at ecma-international.org; Horton, Gareth
Subject: RE: Draft for review: ISO 8601 date work on IS 29500

Hi Rick - first off, many thanks indeed for taking the time to look at this. Very much appreciated. Gareth and I just talked about this for an hour on the phone, and we had a couple of questions.

First off, our dateTime type is indeed a subset of xsd:dateTime, (it's basically xsd:dateTime without time zones). Likewise, our date and time types are also subsets of the equivalent xsd types.

There is a stumbling block though: Because of the multi-purpose nature of cell values, the date must go in an attribute of type string. Is it possible for us to have a string which, in certain circumstances, is a restriction of xsd:dateTime? It was our understanding that this couldn't be done, but neither of us are XML wizards so any thoughts much appreciated. 
Hour "
If we can find a way of getting an xsd:dateTime restriction into a string, would we be right in thinking it would look something like:

<xsd:simpleType name="datetime">
  <xsd:restriction base="xsd:dateTime">
     <xsd:pattern value=".+T[^Z+-]+" />
  </xsd:restriction>
</xsd:simpleType>

We'd obviously need separate ones for date and time, but we wanted to check we were headed in the right direction first.

Chris

-----Original Message-----
From: rjelliffe at allette.com.au [mailto:rjelliffe at allette.com.au]
Sent: 07 July 2010 22:26
To: Chris Rae
Cc: e-SC34-WG4 at ecma-international.org; Horton, Gareth
Subject: Re: Draft for review: ISO 8601 date work on IS 29500

> Hi all - Gareth and I think we have got something to the point where 
> it can be reviewed by WG4. However - this is an early draft. The main 
> areas of interest should be, I think, the line items in 
> "introduction". That summarises the work that we've tried to effect in this draft.

I think it would be useful to

1) confirm that the 8601 date-time subset being used is also a subset of W3C XML Schemas dateTime  datatype, and then, if it is

2) express the date constraints in 18.17.4 in terms of W3C XML Schemas rather than ISO 8601. (Some subset might still be required.)

If the date format allows things not in XSD dateTime, it will not play well in the general XML ecosystem, which goes against the point. XSD Datatypes is more available to developers, and it in turn references ISO 8601.

Cheers
Rick