Re: TMQL: Direct (super|sub)types?
Robert Barta <[email protected]>
| Newsgroups | gmane.text.xml.xtm.general |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Mar 05, 2011 at 10:57:50AM +0000, Andrew S. Townley wrote: > On 5 Mar 2011, at 10:33 AM, Robert Barta wrote: > > > On Sat, Mar 05, 2011 at 09:31:23AM +0000, Andrew S. Townley wrote: > > > >> I'm not saying that TMQL shouldn't be based on a formal model with > >> consistent semantics, but I think I'm a bit confused from the use > >> case as to whether it's supposed to be a scripting language on its > >> own (supported by CTM and TMCL) or whether it is expected to be > >> mixed in or used from host languages. > I guess because I'm seeing it both as an implementor (something I'm > going to have to parse and translate into existing query APIs) and > more along the lines of SQL where it would be limited to DDL and > DML, but any serious logic constructions would be either defined by > some other beast, e.g. PL/SQL or handled by the host language. Well, in the case of TMQL we cannot expect the "host" language to be another query language which takes some of the querying burden. Nor should we actually, as it is a performance bottleneck if there is too much communication between the TMQL processor and the host language. Obviously. > This isn't so say that I wouldn't see the value of "embedded" TMQL > inside an implementation for the same reasons that stored procedures > make sense--closer to the data, much more efficient. Exactly. The experience from the RDF stores is that the networks tend to become large. Some processing can be pushed downwards to the storage, but much global optimization remains on the level of the query language. There it is also most effective. \rho