Draft for review: ISO 8601 date work on IS 29500

[rjelliffe at allette.com.au]

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

Yes.

You can even go more than that, and have a "union type".

This works something like this :

<xsd:simpleType name="datetime">
  <xsd:union>

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


    <xsd:simpleType>
      <xsd:restriction base="xsd:date">
         <xsd:pattern value=".+[^Z+-]+" />
      </xsd:restriction>
    </xsd:simpleType>


    <xsd:simpleType>
      <xsd:restriction base="xsd:long">
         <xsd:maxInclusive value="12345678" />
         <xsd:minInclusive value="-12345677" />
      </xsd:restriction>
    </xsd:simpleType>

  </xsd:union>
</xsd:simpleType>

The types are tested in lexical order: does it match the dateTime?, if not
does it match the date?, if not does is match the long?

Another approach would be to not constrain the data value to remove
timezones, but put in a note that implementations MAY ignore timezones. 
That gives maximum flexibility: if some product or round-tripping wants
the timezones, the capability is there. In general, I like that approach.

Cheers
Rick Jelliffe