[sc34wg3] Questions on N0396: (8) Conformance

Lars Marius Garshol sc34wg3@isotopicmaps.org
19 Apr 2003 19:14:51 +0200


* Lars Marius Garshol
|
| Anything you do to a topic map is processing of it, I would say.

* Jan Algermissen
| 
| Hmm, what about querying it?

That's doing something to a topic map.
 
* Lars Marius Garshol
|
| Basically to conform to the standard. I agree the definition sucks
| badly, and I'm not at all convinced I can improve on it. XTM 1.0
| uses the term "XTM processor", but never defines what it means, so
| there is no help there.
 
* Jan Algermissen
|
| I suggest to drop the concept of processor and the notion of
| processing altogether 

I'll see if it can be done.

| (the interpretation of syntax goes in a deserialization
| specification anyway I think).

It does.
 
| To me the syntax processor has allways been independent from the
| storage, meaning that a 'topic map engine' can exist without the
| notion of processing. To me, conformance in the sense of the SAM
| applies only to the engine, not to the syntax processor.

You now seem to say 'processing' == 'deserialization'.
 
| If the SAM adopted this idea, conformance would only be a matter of
| providing access to the internal information structure in a way that
| is "conceptually equivalent" to the SAM.  What I mean is that a
| conforming softawre must for example provide the possibility to add
| topics to a topic map and to get topics from a topic map. This is
| close to what you have in mind with the 'documented correspondance'.

I think it is nearly identical. The question is what conformance of
this sort buys us. I'm not sure it buys us anything.
 
| I can't (yet) provide the right way to say what I mean, but I hope you
| get the idea. 
| 
| Hmm, what about:
| 
| "An application is conforming if it provides access to/ineraction with
|  the information it 'manages' according to the conceptual abstraction
|  defined by the topic map infoset".

I don't know. What does this buy us? Why should we have it?
 
* Lars Marius Garshol
|
| I agree completely. The question is what to do about it. I think the
| solution is to do away with the concept of SAM conformance entirely,
| leaving the SAM as only a tool to be used by the other
| specifications.
 
* Jan Algermissen
|
| Well, that is not enough. I must be sure that a SAM conforming
| implementation provides a way to, for example, add an occurrence to
| a topic. I must be sure that the implementation provides the
| semantics defined by the SAM to interact with it.

Well, of what value is that? I'm serious. The purpose of a standard is
to ensure interoperability, not to ensure that implementations meet a
certain quality threshold. The conformance section should either give
us better interoperability or go, is my view.
 
* Lars Marius Garshol
|
| What do you mean? I can't think of any topic map engine that does
| not effectively implement SAM (or something very close to it) except
| your own.
 
* Jan Algermissen
|
| Wait a minute....if you can't say how to verify SAM conformance, how
| do you know?
| 
| OTH, this last sentence is exactly what we need to talk about to get
| to the conformance 'solution'. What does it mean to 'effectively
| implement SAM' ?

As it stands now: to use an internal representation equivalent to the
SAM. 
 
| Example: I can implement a Python module on top of my code that
| provides exactly the object oriented 'version' of the N0396 topic
| map infoset (section 3). Is my implementation conformant then?

Yes.
 
| Is only the wrapper conformant because it provides the API or is the
| underlying (graph based) C code conformant too, because it allows me
| to build the Python wrapper on top?

Depends how much is in the wrapper. If there is an equivalent
structure underneath the C layer would be conformant, too. An RDBMS
would *not* be conformant, even though you could build a SAM
implementation on top of it.

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