RE: gYear etc. datatypes

We've deliberately tried to keep the function library small this time round,
in the knowledge that it's easy to grow it later in response to real user
demand, whereas it's impossible ever to take things out.
 
It wouldn't be conformant to add functions or operators for these types to
your own implementation unless you did it using the defined extension
mechanisms in the language (e.g. you can define your own functions in your
own namespace).
 
For XSLT 1.0 there's a set of vendor-neutral extension functions specified
at www.exslt.org - these have the advantage that vendors can pick and choose
which of them they think are worth implementing, but if several vendors
implement the same function then they are portable across implementations.
It would be nice to see this kind of mechanism used for the kind of
extensions you are proposing.
 
I think most people on the WG felt that providing full support for the
xs:gYear family of types was over the top. 
 
Michael Kay
http://www.saxonica.com/
(personal response)


  _____  

From: www-ql-request@w3.org [mailto:www-ql-request@w3.org] On Behalf Of
Pavel Velikhov
Sent: 05 June 2006 13:51
To: www-ql@w3.org
Subject: xs:gYear etc. datatypes


Hi,

  We have incorporated support for all date/time datatypes into our DBMS,
however the usage of xs:Year, xs:YearMonth, etc. datatypes seems to be
extremelly limited. Neither accessor functions, nor comparison operators
(except for equality) are supported on these datatypes. Are you planning to
make these datatypes first-class citizens at some point in the future and
will be going on the wrong track by adding accessor functions and
comparisons for these datatypes in our system?

Thank you,
Pavel Velikhov
Sedna XML database team