[tmql-wg] Result set requirements

[Lars Marius Garshol]

* Lars Marius Garshol
|
| Don't you think that the very design of the TMQL would bind us very
| strongly to TMDM anyway?

* Robert Barta
| 
| 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.

Ah, yes, I see. You *could* do that, but I think in practice we will
need that capability. (Certainly a lot of applications I've built have
needed it.)
 
| 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.

I agree this is an issue, though thankfully it's one we can avoid. We
can even have everything tied to a single model.
 
| 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.

Well, I'm not sure that can be avoided. How can you write TMQL queries
without understanding the structure that is being queried? (Note that
the requirement is not that implementations provide something that
follows TMDM to the letter and comma, but rather that they provide
something equivalent. Returning TMAPI objects is perfectly fine.)
 
| 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.

I'm not sure there's any gain to disallowing some of the item types.
 
| 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

Actually, in our Web Editor Framework we need to get the actual base
name. That would account for ~5% of the cases, I think, at least in
our use of tolog.
 
| 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.

As indeed they should; though it should be noted that there can be
many approaches to typing. tolog doesn't have explicit typing in the
language, yet it is sufficiently amenable to analysis that the current
tolog implementation in the OKS can infer the possible types of every
variable used in a query.
 
| Introducing all TMDM data structures would probably add another
| type dimension into TMQL.

One that is already there, I'd say.
 
| 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

I think if *want* to do this it's not too hard to come up with a
reasonable syntax (or even semantics) for it.

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