Things it needs to do

Existing Languages

XQuery

ASCII language. Generally applied to XML data and returns ASCII (usually XML) data. Could be adapted to apply to any data I should think, but still based around returning ASCII results.

XML form (XQueryX ) suffers from verbosity (similar to ADQL) and seems to have been abandonend

SQL

Can only manage relational tables. Could possibly change aliases to columns rather than tables, and so introduce XPaths (as with SADQL). No readily available parses. Well known.

XQL

XML-QL

ADQL

Horribly verbose but recent changes appear to solve this. Can only manage relational tables. High change inertia; very unlikely to be able to include XPaths for example instead of columns. Expect to convert this to something more general in the guts of the datacenter.

SADQL

Apart from being absolutely wonderful: May not be complete. Can query heirarchical and table data by using aliases to represent columns and/or XPaths. Not as flexible as XQuery, particularly re how to define results. Easily extended as it's 'ours'.

Possible Solutions

Multiple Languages

The current method is to just take anything, and worry about it at the back end. This is a Bad Thing as it produces a whole stack of n x m conversions. On the other hand perhaps we can reduce this to an n -> a -> m conversion where a is very small; and the plugin mechanisms at the back might be the best place to assemble the translators.

It's still a Bad Thing though in that we don't define properly at the interface the 'contract' as to what the datacenter will accept.

Roll our own

-- MartinHill - 02 Mar 2004