RE: ISSUE-126 (Revisit Datatypes): A new proposal for the real <-> float <-> double conundrum

> >Similarly, there seems to be missing an underlying type for the date 
> >types - although there is reference to timeOnTimeline, this 
> value type 
> >is not surfaced in the type hierarchy.
> 
> I'd very much like to hear how you'd do this; unlike the 
> number datatypes, where I could envisage how to pull them 
> together, I can't envisage a reasonable way for all the d/t 
> datatypes to be derived from a universal one.  And I did try.

Since the types date, time, dateTime, gYear, gYearMonth, gMonth, gMonthDay,
and gDay are disjoint in both their value spaces and lexical spaces, I would
have thought it quite easy to define a primitive type that is essentially
the union of all of these (it might or might not be abstract), and derive
these 8 types from this new type by restriction. Where exactly is the
difficulty?

The QT operations on dates and times could be greatly simplified if this
were done (well, perhaps not retrospectively...)

> 
> base64Binary and hexBinary are different because they use 
> entirely different lexical mappings.  Different lexical 
> mappings mean different datatypes.

This is certainly an unfortunate feature of the system. Clearly one would
like all operations defined on one of these types to be equally applicable
to the other. Having two different external representations of the values is
really a very weak justification for making them different types. Of course
it's too late to change this; but I'm sure it could have been done better. I
would hope that if we introduced hexadecimal notation as an alternative
lexical representation of integers we would find some way of doing it that
didn't involve introducing a new primitive type.

Michael Kay
http://www.saxonica.com/

Received on Saturday, 5 July 2008 11:42:52 UTC