[tmql-wg] Result set requirements

[Robert Barta]

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

  foreach $a [ (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