[tmql-wg] TMQL, next round

[Lars Marius Garshol]

* Robert Barta
>
>    At the moment, TMQL has a rather arbitrary choice of primitive data
>    types: integer, URIs, decimals, datetimes, most of them cloned from
>    the XML schema data types
>
>         http://www.w3.org/TR/xmlschema-2/datatypes.html#typesystem

For our Ontopoly editor we chose these datatypes:

  - Date
  - Datetime
  - Number
  - String
  - URI

Like XPath 1.0 we made no distinction between integers and decimals.  
These are all the XSD datatypes.

This selection has worked very well for us in practice, and we've had  
no requests for extensions yet, and all types really do get used.

I think the types that *could* be lost are date and datetime. None of  
the others can really be left out.

The value of date and datetime is really that
  - you get proper ordering for them without having to encode them
    in ISO 8601 format, and
  - it's a bit easier to apply "nice" formatting to query results.

The downside is that date and datetime are tricky, complicated devils  
to deal with, and there is no end to the potholes awaiting the unwary  
in this area. XPath/XSLT 1.0 got by just fine without them, so...

Another question is whether we need an XML datatype, since TMDM has  
it...

>    Structured Discussion
>
>       ? should all types from XSD be understood?
>         + very rich collection, strong big-vendor support
>         + constants can be written 'naturally' (3 instead of  
> "3"^xsd:integer)
>       => also all XPath 2.0 functions and operators have to be  
> supported
>         - very expensive to produce for small developers

I think the set of functions which need to be supported isn't  
necessarily determined by the set of datatypes we choose to include.  
For example, it's possible to include date and datetime without  
having a big library of time functions.

What we really need for all built-in types, I think, is:
  - a literal syntax,
  - comparators.

Possibly also atomification and de-atomification.

The set of datatypes isn't necessarily expensive to implement, but  
having a rich set of functions for them definitely does increase the  
load.

--Lars M.