[tmql-wg] Proposed changes to existing requirements

[Lars Marius Garshol]

* 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
| ? ;-) 

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."

I'm uneasy about putting in too much distributed querying stuff into
TMQL since I feel that that really belongs in implementations.
Holger's requirement just said that we should avoid screwing that up
for implementors, which is good. The way you formulated it it went
into the how, which I try to avoid.

Anyway, does my reformulation cover what you want?

| As for useful? <shameless-plug>Wait till you see peer-to-peer topic
| maps in action at XML Europe 2003</shameless-plug>

* Lars Marius Garshol
|
| RFC 2732 adds support for IPv6 IP-addresses in URIs. So 2396+2732
| means you need a more up-to-date URI parser than with only 2396.
| That's really all.

* Kal Ahmed
|
| Oh, in that case I have no problem with that at all.

Good.

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