[tmql-wg] TMQL, next round
Lars Marius Garshol
larsga at garshol.priv.no
Thu Mar 8 19:08:54 EST 2007
* 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
For our Ontopoly editor we chose these datatypes:
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
> Structured Discussion
> ? should all types from XSD be understood?
> + very rich collection, strong big-vendor support
> + constants can be written 'naturally' (3 instead of
> => also all XPath 2.0 functions and operators have to be
> - 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,
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
More information about the tmql-wg