[sc34wg3] Clarifying N0323

[Robert Barta]

I'm not sure whether I have posting privileges. Anyway:

On Thu, Feb 06, 2003 at 06:08:48PM +0100, Lars Marius Garshol wrote:
....

Everything looks _very_ workable to me.

....
>   ISO 18048 - TMQL
> ------------------
> 
> This standard will provide a way to query topic maps both to extract
> information and later also to change the topic maps. It will be

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.

> Note that being "specified in terms of" the SAM means that if TMQL
> were, for example, tolog-like and had a built-in predicate
> "occurrence" its behaviour would be explained as something like this:
> 
>   A predicate clause of the form
> 
>     occurrence($A : topic, $B : type, $C : locator)
> 
>   would produce a virtual table of three columns, where there would be
>   one row for every occurrence item in the topic map. The A column
>   would hold the topic item in whose [occurrences] property the
>   occurrence item is found, the B column the topic item in the
>   occurrence item's [type] property, and the C column the locator item
>   in the occurrence item's [resource] property.
> 
> This is how syntax independence and formality can be achieved at the
> same time. (Feedback wanted.)

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.

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.

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

>   XTM Conformance
> -----------------
> 
> I think we should create an OASIS TC chartered to create an official
> XTM conformance test suite. This test suite should consist of a set of
> XTM documents, a set of Canonical XTM documents, and a topic map that
> describes the test cases.

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.

Either this, or further down the road, a reference implementations can
reduce open discussions about the standard. This has killed some in
the past.

We need negative test cases (and the errors they should flag) as well.

\rho