[tmql-wg] Proposed changes to existing requirements

Marc de Graauw marc@marcdegraauw.com
Fri, 11 Apr 2003 11:23:13 +0200


* Kal Ahmed
|
| Let me propose: "TMQL results sets will be topic maps. Aggregation
| of TMQL results sets will be performed according to the topic map
| merging rules of the SAM". How's that for fitting into the standard
| ? ;-)

* Lars Marius Garshol

| That's clear, straight, and unambiguous, but unfortunately I'm very
| unhappy with it. I see that there are people who want TMQL result sets
| to be topic maps, but as I see it part of what I want to use TMQL for
| involves picking strings and numbers out of topic maps (for use in an
| application) or selecting individual topics for use in another context.
|
| In other words, I see TMQL kind of like XPath, as something that does
| a TM -> X transformation where X is something that is more tractable
| when you want to use TM information in an application.
|
| *However*, I do see that using TMQL to do TM -> TM transformations
| certainly also has its uses. I don't think this is a black and white
| thing, however.
|
| Let me propose:
|
|  "It shall be possible to interpret TMQL result sets as topic maps."

It looks to me like you want a TM Query Language and a TM Transformation
Language all in one package... Looking at SQL, the result of a query has the
logical structure of a table, which is very handy (for instance if you want
to store the results physically as a table). It seems to me Topic Maps would
benefit using the same approach, i.e. the result of a TMQL query is a topic
map again, and nothing else. Then one can have a separate technology for
transforming topic maps to other formats, i.e. (lists of) strings or
numbers. Conceivably this other technology could be part of the TMQL
standard, but I wouldn't call such transformations TMQL queries or TMQL
result sets.

Marc