[sc34wg3] Clarifying N0323

[Lars Marius Garshol]

* Robert Barta
| 
| Everything looks _very_ workable to me.

Good to hear. :)

| [TMQL]
| 
| I suggest to change the agenda to
| 
|     ...maybe later.....
| 
| I would not be too happy about a query language doing modifications
| as well. That SQL (aka the ugly one) has schema management, query,
| update and delete within one 'language' should be a negative
| example, IMHO.

I'm surprised by this, actually. I agree that using TMQL as a DDL is
not the right thing, but why shouldn't it do modifications? I think it
makes a lot of sense to have a declarative language for modifying
topic maps. Don't you? Or is your objection something else?
 
| I cannot yet see/understand this fully. Every implementation will
| have to create a formal model for the output data structure and will
| have to define this. It is then difficult to argue about
| conformance.

I'm not so sure that conformance testing will be difficult, actually.
You can create a canonical TMQL result set syntax in XML and build a
test suite around that with XTM documents and TMQL queries as inputs.

Where do you expect the problems to occur?

| Would it be possible to charter TMQL as SAM -> SAM transformation? I
| would guess it would make a lot of sense to query engines to render
| TMs again and not tables or lists or tuples or what have you.

Sure. The decision on what form TMQL results is to take hasn't been
made yet. That description describes tolog, not TMQL. I wanted to give
a rough idea of the sort of language you'd find in the TMQL spec; that
is, show *how* it would depend on the SAM. This seemed to be unclear
for many people, so I felt it was useful to illustrate.
 
| Any implementation can take the result (logically conformant to SAM)
| and can then produce something which the application can pick up
| easily.
| 
| We could use your test case idea using pairs of
| 
|     CXTM -> CXTM

Actually, I'd do XTM -> CXTM, since I don't expect anyone to create
CXTM importers. But sure, we will probably need something like that.
(We'll be busy working on topic maps for a loooong time, I'm sure. :)

| [XTM conformance test suite]
| 
| I would strongly encourage this, although the maintenance is a major
| issue. Still, I think that a standard (or set of standards) is much
| more reproducable to pot. implementors if there is a complete set of
| test cases.

Maintenance of the test suite is an issue, for sure, but it's also a
very effective way of testing the quality of implementations, and also
of the specification text. 

(Actually, the test suite will most likely be very useful for
implementors as well. Ontopia has found its automated test suite
(which includes an XTM conformance test suite) *invaluable* for
producing quality software.)
 
| Either this, or further down the road, a reference implementations
| can reduce open discussions about the standard. This has killed some
| in the past.

Not sure if ISO does reference implementations, and personally I
haven't really seen the point of them. What good would it do us?
 
| We need negative test cases (and the errors they should flag) as
| well.

Agreed. Testing that the correct errors are flagged may not be
possible to automate, but yes.

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