RE: gYear etc. datatypes

"Michael Kay" <[email protected]> Mon, 5 Jun 2006 14:49:09 +0100
Newsgroups gmane.comp.web.query-languages
Message-ID <009d01c688a6$d1e3be30$6401a8c0@turtle>
This is a multi-part message in MIME format.

------=_NextPart_000_009E_01C688AF.33A82630
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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: [email protected] [mailto:[email protected]] On Behalf Of
Pavel Velikhov
Sent: 05 June 2006 13:51
To: [email protected]
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



------=_NextPart_000_009E_01C688AF.33A82630
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.2873" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We've deliberately tried to keep the function =
library small=20
this time round, in the knowledge that it's easy to grow it later in =
response to=20
real user demand, whereas it's impossible ever to take things=20
out.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>It wouldn't be conformant to add functions or =
operators for=20
these types to your own implementation unless you did it using the =
defined=20
extension mechanisms in the language (e.g. you can define your own =
functions in=20
your own namespace).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>For XSLT 1.0 there's a set of vendor-neutral =
extension=20
functions specified at <A =
href=3D"http://www.exslt.org">www.exslt.org</A> - these=20
have the advantage that vendors can pick and choose which of them they =
think are=20
worth implementing, but if several vendors implement the same function =
then they=20
are portable across implementations. It would be nice to see this kind =
of=20
mechanism used for the kind of extensions you are =
proposing.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I think most people on the WG felt that =
providing full=20
support for the xs:gYear family of types was over the top. =
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Michael Kay</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><A=20
href=3D"http://www.saxonica.com/">http://www.saxonica.com/</A></FONT></SP=
AN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D464214313-05062006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>(personal response)</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email protected]=20
  [mailto:[email protected]] <B>On Behalf Of </B>Pavel=20
  Velikhov<BR><B>Sent:</B> 05 June 2006 13:51<BR><B>To:</B>=20
  [email protected]<BR><B>Subject:</B> xs:gYear etc. =
datatypes<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, =
times, serif">
  <DIV>Hi,<BR><BR>&nbsp; We have incorporated support for all date/time=20
  datatypes into our DBMS, however the usage of xs:Year, xs:YearMonth, =
etc.=20
  datatypes seems to be extremelly limited. Neither accessor functions, =
nor=20
  comparison operators (except for equality) are supported on these =
datatypes.=20
  Are you planning to make these datatypes first-class citizens at some =
point in=20
  the future and will be going on the wrong track by adding accessor =
functions=20
  and comparisons for these datatypes in our system?<BR><BR>Thank =
you,<BR>Pavel=20
  Velikhov<BR>Sedna XML database =
team<BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009E_01C688AF.33A82630--