[tmql-wg] Result set requirements

[Robert Barta]

On Tue, Mar 16, 2004 at 02:09:54AM +0100, Lars Marius Garshol wrote:
> | But I am not talking (writing actually) about types in the sense of
> | the implementation (what kind of item in terms of TMDM), but typing
> | in an application-specific sense.
> | 
> | In XQuery there are not only those types of WXS (the predefined
> | ones, number, integer, ....), but also this [ not real syntax ]
> | 
> |    element Book := ( element Title, element Author )
> | 
> | This 'typing' gives queries a boost but requires a strong mechanism
> | to define the type. In the TM area this would be the task of an
> | ontology language.
> 
> I've seen the XQuery folks do this, though I have to say I am not very
> keen to follow in their tracks. This quickly gets very complicated,
> and to make use of it requires an unusually advanced implementation,
> plus close integration between QL and CL. There's a lot of pain down
> this route; I'm not convinced there's a lot of gain.

I think there is. At least those small parts which I understand from
functional programming (Hendler et.al.) points strongly in this
direction.

My gutt feeling says 'typing' is even more important for TMQL in terms
of potential speed benefits than for XQuery. My conjecture is 'the more
irregular a data structure is, the more a query language has to rely on
input from the application developer'. And TM allows more flexibility
than XML, I suppose.

> To top it all, I'm not sure you need to integrate things as closely as
> the XQuery/WXS folks have actually done.

The trick they have accomplished is that XQuery works with NO TYPE
INFORMATION as well. But the, of course, fewer optimizations can be
done. The research papers (Chamberlin, Fankhauser) are quite
interesting.

   http://topicmaps.it.bond.edu.au/mda/markup/xml/xquery/xquery

> Are you advocating this approach, or just describing what the XQuery
> gang did?

Not sure. I would love to see something like this, but this would need
much much much more consideration and is beyond my capabilities.

> | I do not see this coming with TMCL.
> 
> What do you mean?

I am not sure about the future of TMCL. At the moment it looks like
RDFS light.

\rho