# [tmql-wg] Result set requirements

Robert Barta rho@bigpond.net.au
Tue, 24 Feb 2004 07:20:25 +1000

On Mon, Feb 23, 2004 at 09:46:34AM +0100, Lars Marius Garshol wrote:
>
> * Robert Barta
> |
> | I would assume that a
> |
> |       select topic.bn ... > | > | could be reasonably defaulted to 'string' output. > > Actually, I'm not so sure. We currently have queries that do return > topic name items, and that need to do so. So I think there needs to be > a way to distinguish between the item and its string value. Yes, that's true, but... > | What I am bit sceptical about is to allow _any_ kind of node type in > | the result. So, to allow basename and occurrence and this and that > | items as described in the TM DM as possible parts of a list result. > | Going that path would link TMQL standard-wise VERY STRONGLY to TMDM > | and I am not a friend of strong couplings. > > Don't you think that the very design of the TMQL would bind us very > strongly to TMDM anyway? Yes, we will probably do it this way, but it does not need to be this way. I could, for instance bind the semantics of AsTMa? onto TMDM underneath and could choose NOT to return any TMDM items. Maybe there are dependencies I do not see yet... * Robert Barta | | I am rather sceptical about "query languages" which return "nodes" | or other internal data structures. This is like XPath and has the | problem that you have to use XPath _always_ with something else: | XSLT, XQuery, or a programming language. > Lars Marius Garshol wrote: > I'm surprised to hear you describe this as a problem. I've seen this > as one of the great strengths of XPath, and a major part of why it's > been such a resounding success. XML development without XPath would be > horribly much harder. Sorry, too fast and sloppy writing. It is not a problem that "you have to use XPath _always_ with something else". That you have the same sublanguage XPath in XQuery/XSLT/Schematron is actually a nice thing to have. It is a problem for the language designers to find the right level of abstraction how XPath interacts with these languages. It is actually only now that XPath 2.0/XSLT 2.0 is aligned with XQuery 1.0 and the alignment with the DOM2 came also rather late. [ XPath is harmless in the sense that it can return nodes and those are basically DOM nodes. And XPath _in many_ case silently converts nodes into string: /..../....[some-element = "Rumsti"] So that is an _easy_ model for a developer. ] If we would allow TMQL to spit out everything the TMDM offers us, that would, I think, drive the complexity for developers up. They would have to learn TMDM AND TMQL at the same time. It would be a rather high entry price for me as a developer. -- > If not, how do you think we can avoid that? > | One option would be to allow only maps or fragment thereofs and let > | TMQL be completely opaque about this. > > How does that work? I had this problem with AsTMa? as well. Here I decided to allow only _one_ data structure to be passed back, that of a maplet (it is nothing else than an association _including_ all necessary topic data). So, if you say foreacha [ (is-associated-with) # I like that one, it comes from a student map
] return $a you get a list of these associations together with the topics they include (type, scope, roles, players). If you say foreach [$p (person) ] return $p you also get a list of maplets (a single topic is a trivial maplet). -- With that I simplified things for me as language designer and hopefully also the developer. If he/she chooses only to see strings, then the AsTMaPath expression gives this: foreach [$p (person) ]
return $p/bn # returns only the basename as string If the developer then likes climbing through the data structure, then he asks for$p only and drills down himself.

> | Another (mumble, mumble) would be to allow topics and assocations
> | only, but this has some problems....
>
> Yes... :-)

I think we _should_ allow to pass out structures. Again, whether we
can simply inject all of TMDM into the language is less clear to me.

If I say in Toma

select $t.basename, ..... and I get a basename item where in 99% of the cases I am interested in the string, I would not be too happy to do the XPath-like conversion select string($t.basename), ...

Argh, I do not like typing :-)

--

Another consideration in this context is 'typing'. XQuery has done
that to quite some extent and I know that many people in the database
community take that quite seriously for an excellent means to arrive
at some performance.

Introducing all TMDM data structures would probably add another
type dimension into TMQL.

--

One option we have is to treat this as "language pragma"

pragma INTERFACE_MODEL (TMDM)
return $t/bn # returns basename item pragma INTERFACE_MODEL (simple) return$t/bn   # return string

pragma INTERFACE_MODEL (maplet)
return $t # returns topic as part of a maplet only allowed on the outest level so that it does not affect language semantics, but only interface semantics. Or, to choose a reasonable default and use 'ATTRIBUTE' (meta-information on data): return$t/bn'TMDM   # returns basename as item
return $t/bn # default is stringification return$t/bn'VALUE  # same

--

\rho