[sc34wg3] Questions on N0396: (8) Conformance

18 Apr 2003 19:05:27 +0200

* Jan Algermissen
| 
| - (Section 1): I don't understand what a topic map processor is.

Essentially it is the same as a topic map engine.

Anything you do to a topic map is processing of it, I would say.

|   Do you mean a topic map in the N0396 sense or a topic map document?

In the SAM sense.

|   What does 'process ... in conformance with this standard' mean?

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.

Based on feedback from you and Robert I'm beginning to wonder whether
we should ditch both concepts and simply do without them. I've looked
through the text quickly and as far as I can tell it shouldn't be too
hard.

I'll see what I can do.

|   When you write (also section 1):
| 
|   "It is assumed that a topic map processor will do deserialization
|    on behalf of the application, and that the processor will manage
|    the topic maps on behalf of the application."
| 
|   you seem to talk about topic map documents ('deserialization').
|   I think a clear differentiation between 'topic map' and 'topic map
|   document' would help to clarify this paragraph.

|   Also, could you define what a 'topic map application' is?
| 
|   Is it the 'store' in which the topic map is stored?

No, that would be part of the processor. The application is the
software that uses the processor to do something useful for the end
user. 

| - conformance
|   
|   Section 1 also says:
| 
|   "Topic map implementations must have internal representations of
|   topic maps that have a documented correspondence to the model defined
|   in this Technical Specification. A number of structural constraints
|   and operations on instances of the model are defined, to which
|   implementations must conform."
| 
|   Section 6 says: 
| 
|   "The topic map processor must make all the information described
|   in 3 Information item types available to applications, and document
|   how its representation of topic map corresponds to the model defined
|   in that section."
| 
|   I don't understand what that means, can you provide an example
|   (sketch) of such a 'documentation'?

When I wrote this I was thinking that it would go something like
(using TMAPI as an example):

 - the TopicMap class corresponds to the topic map item, the
   getAssociations() method to the [associations] property, the
   getTopics() method to the [topics] property, the
   getSourceLocators() method to the [source locators] property, and
   the getBaseAddress() method to the [base locator] property,

and so on.

I'm not sure this is a very good idea, however, and I'm not at all
convinced that we should keep it in there.

|   Does it mean that the implementor must reveal the details of the
|   internal representation and how it maps to N0396? 

No, only the interface exposed to applications.

|   Section 6 also says:
| 
|   "The topic map processor must detect all attempts to add duplicate
|   values to set properties, and also perform all merges according to
|   the rules of section 4 Merging."
| 
|   What is an "attempt to add duplicate values to set properties"?
|               ^^^^^^^
|   
|   And, since they are sets, doesn't the set-ness imply that no
|   duplicate values exists anyway?

Exactly. But trying to add a new member to a set that already has that
member in it is an attempt to add a duplicate. It will only be an
attempt, however, since that will trigger merging and so the member
will not actually be added.

|   Also I don't understand why the topic map processor must perform
|   merging?  Isn't the processor only deserializing syntax?

It is, but part of deserialization is to do merging. 

| I have been spending most of my time in the last three years on
| implementing topic map software and I think I understand what you
| have in mind, but N0396 does not make it clear to me, what a
| conforming application would look like nor how to verify its
| conformity.

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.

Reactions on this would be welcome.

| All RM vs. N0396 fightings set aside, and regardless of the final
| result, I think this MUST be absolutely clear if we want ISO13250 to
| evolve beyond being DTD based.

Not sure what you mean by "this" here.

| Has anyone implemented N0396 or its precedents?

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. 

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