[tmql-wg] Proposed new requirement: Ability to produce textual output

Lars Marius Garshol larsga@garshol.priv.no
02 Jul 2003 12:20:36 +0200

* Robert Barta
| I have little imagination, though, how much potential performance
| penalty we will have to pay if we _completely_ would decouple any
| serialisation (XML, flat text, XTM, ...) from the query language and
| have them as "plug-ins" (or actually, plug-outs).

If you look at actual XSLT implementations like SAXON you'll see that
the XPath implementation is designed to accept hints from the layer
around it that helps the XPath implementation perform better. This was
designed for the XSLT implementation to use, and probably does speed
up SAXON quite a bit.

A trivial example is that when evaluating an XPath expression you can
say that what you want is only the first node in the node set. That
means the XPath expression can search for matching nodes and stop when
it finds the first one. This is useful for <xsl:value-of/>, for

In TMTL I can also see that if my TMTL implementation looks into the
tolog queries being used it can rewrite them to optimize the TMTL page
as a whole, and it can provide similar kinds of hints to the tolog
implementation inside it.

| In one of the first versions of AsTMa? I tried to completely
| separate the two issues, but simply failed as it made the language
| definition so vague.

I agree that you can't separate the two completely. What you can do is
make one use the other, or define an intermediate layer of some kind.
TMTL takes the first approach, and believe Chris is suggesting a
variant of the latter approach.

I think the conclusion is that what is needed is

 a) for the query result / output production interaction to be
    well-defined, and

 b) for implementations to integrate querying and output production
    (in order to achieve maximum performance).

Sounds like we are on the same page on this.

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