[tmql-wg] Proposed requirements: Operations on primitive types

[Lars Marius Garshol]

* Robert Barta
| 
| This is a tricky one.

Indeed. It's one of those "this is very nice, but also very complex"
issues, where we have to justify the cost of whatever we include, and
run the risk that whatever we do not include now must perforce be
included later.
 
| On the one hand the official TM standards so far are oblivious to
| typing: except 'string' I cannot remember seeing anything yet, maybe
| at some time in TMCL.

There's no typing in any existing standard or any existing draft of
one. 
 
| On the other hand it is a frequent developer request to add all
| sorts of data into a resourceData element. There is no TM-ish way to
| indicate _what_ kind of data one adds. For a constraint/template
| language it may mean that validation also includes the validation of
| content in the resourceDate element. What if this is XML? Should
| another validator be launched? Should a DSDL framework (shiver :-)
| be used?

This pretty much sums up my own thoughts on this. I do think TMCL
should also support type validation, but what to do about XML is not
entirely clear. It does seem reasonable, though, that validation of
XML also be supported, though for it to be optional seems reasonable.
 
| What I am saying is that a query language rightfully may take the
| stance to ignore typing altogether, even though it is ultimately not
| very practical.

I agree, on both counts, and I think for us it is more important to be
practical than righteous. :)
 
| What I would imagine is that we include minimal integer arithmetic
| (+,-,*,div,mod) and maybe some string functions (length, substring,
| concat/join) and use a (perlish) implicit conversion mechanism.

I've been thinking the same. The implicit conversions of XPath 1.0
seem to me very successful, but I find Dmitry's suggestions about
constructor functions a la XPath 2.0 quite interesting.

We might also want to do like XPath 1.0 and go for floats instead of
integers, as integers only seems a bit restrictive. (There's also the
numeric tower approach that Scheme took, but while that is clean and
attractive I think it's way over the top for us.)
 
| Everything else might be tucked away into 3rd party function
| libaries.  

Yep. If we have a clean extension mechanism we can let people create
what extensions they need, and then later take the most
common/necessary extensions and add them to the language.

| Maybe there are some suggestions about dates, though, as they appear
| quite frequently.

Dates are very important, IMHO. I've yet to do a real project that
does not involve them. One can get quite far without them, but some
things become very hard without them.

To illustrate:

 - adding a "last-updated" time stamp on topics can be done as simple
   strings,

 - ordering search results by this can be done as simple string
   ordering provided an ISO 8601 format is used, but

 - limiting the result to topics changed in the last week is difficult
   (though it can be done by computing a date string and doing a
   string comparison on it in the query), but

 - counting the number of topics changed in each week is not doable
   without a date type and functions to work on it.

It may be that getting a proper use case collection is the right way
to handle this issue. If we really have a representative collection of
use cases we should be able to see the cost of leaving features out
quite clearly.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >