[tmql-wg] Proposed changes to existing requirements

[Lars Marius Garshol]

* Robert Barta
| 
| But then we should elaborate it as, say:
| 
|   "TMQL should provide (features|mechanisms|language constructs) to
|   access Topic Maps (or parts thereof) from different TM
|   repositories".
| 
| Which implies that a 'TM repository' must be defined somewhere.
| Maybe this could then be merged with the issue last in this email.

Yeah. The only difficulty is that I believe that TMQL should be
defined as independent from any access method or API. This applies to
both accessing TMQL processors as well as the TMs themselves. As I've
envisioned it, TMQL should be a function that takes a TM, an
environment, and a query and produces a result set.

The reason I see it this way is that to my mind a large part of the
value of having a declarative TMQL is that it can be used in a large
number of different contexts and languages (just look at how many
different places XPath is being used) and to leave access options open
is to widen the possible usage areas.

Of course, there is value to having standardized mechanisms for
accessing TMQL processors, the question is just what to do about it.
The way of defining TMQL that I sketched above means you can create a
separate specification that provides both a TMQL access method and
access methods for TMs. (Note that requirement 4:1 says a TMQL
processor access method may be defined in a separate part later.)

Given all of this, do people think that we should put in something
like:

  "TMQL may contain one part that provides mechanisms to access Topic
  Maps (or parts thereof) from different TM repositories".

Now that I look at that requirement I don't really like the way it's
phrased. Maybe we should say that TMQL should provide this mechanism,
but that it may be outside the language itself, in a separate part?
Something like:

  "TMQL should provide mechanisms to access Topic Maps (or parts
  thereof) from different TM repositories. These mechanisms may be
  part of the language itself, or specified as a separate part outside
  the language."

* Lars Marius Garshol
|
| Do you think we should put the web services thing in as a
| requirement?
 
* Robert Barta
|
| Not as a hard requirement. (I would expect a TM-WS to be a rather
| useful application scenario, though.)

I agree. So unless someone speaks up for this option I'll just leave
it. 
 
| Hmmm, for instance:
| 
|    Inter-query context
| 
|    This is the execution context for TMQL queries, as modified by
|    previous queries. It is not clear what this context may contain.
| 
| If previous queries Q_1..Q_N-1 have _any_ effect on a particular Q_N,
| then this implies that this effect is the effect of the LAST query
| Q_N-1. (At least if we talk about the usual state machines).

Not necessarily. For example, query Q_M (where M < N-1 and M > 0) may
have bound a variable/function/predicate/whatever that is accessible
to the following query. Conceivably. Whether we actually want this, I
don't know.

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