[sc34wg3] Issue (term-tm-processor)

Lars Marius Garshol sc34wg3@isotopicmaps.org
27 Aug 2002 14:05:12 +0200


* Mary Nishikawa
| 
| Issue (term-tm-processor):
| Do the definitions of the terms 'topic map processor' and 'topic map
| applications' have unwanted consequences for what software
| architectures can be conforming implementations of this standard?
| ------------------
| 
| We all agreed that the answer to this was "yes." 

We agreed that the answer was that they might, but that we could work
around that by wording the conformance clause in the right way.

| We agreed to define the term "topic map processor", but not define
| "topic map application."  Is this correct? 

Not really. We will define both, but not constrain what instances of
the second are allowed to do.

| If we do not define "topic map application," then we do not need to
| discuss this serialization and deserialization business.

We don't anyway. It's not really related to this question. :)
 
| I want to confirm that we agreed not to define "topic map
| application" in the SAM. Is this correct? If it is then, don't we
| still need to possibly define what an XTM application is, in general
| terms at least in the SAM?

We would, but we now do away with that by defining "topic map
application" as something independent of whether the application
happens to use XTM syntax, HyTM syntax, or perhaps no syntax at all
(database).
 
| I think that there is some ambiguity in how "application" and
| "processor" are used in the XTM spec.
| 
| We have three terms, "XTM processor" and "XTM processor application"
| and "XTM application" in the XTM spec.  We have terms such as
| "application-specific processing" all over the place.
 
Actually, the XTM 1.0 glossary defines none of these terms. I see that
it does use all of these terms and I would guess that they are all
meant to be equivalent, but since there was no officially defined term
the editors ended up using three different terms for the same thing.

All of this will be replaced by "topic map application", however, so
this is one problem that the new ISO 13250 will fix.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >