
Some parts of this message have been removed.
Learn more about Nabble's
security policy.
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
(personal response)
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