[sc34wg3] Questions on N0396: (8) Conformance
Jan Algermissen
sc34wg3@isotopicmaps.org
Sat, 19 Apr 2003 10:07:53 +0200
Lars Marius Garshol wrote:
>
> * Jan Algermissen
> |
> | - (Section 1): I don't understand what a topic map processor is.
>
> Essentially it is the same as a topic map engine.
So, what's a topic map engine? (just joking, I see what you mean.)
>
> | N0396 says that it is
> |
> | "any module or system that can process topic maps in conformance
> | with this standard."
> |
> | What does it mean to 'process a topic map'?
>
> Anything you do to a topic map is processing of it, I would say.
Hmm, what about querying it?
>
> | 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.
I suggest to drop the concept of processor and the notion of processing
altogether (the interpretation of syntax goes in a deserialization
specification anyway I think).
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.
The syntax processor in turn must conform to ("behave according to") a
particular deserialization specification.
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 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".
>
> 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.
I think it is a good idea.
>
> | 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.
Well, something like this is needed, but (see above) I am not
capable of saying what exactly. It has something to do with
constraining the semantics of the implementation...
>
> | 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.
Ah. To me, deserialisation is calling methods of the topic map
engine in the right order and with the right parameters. The merging
(to me) is handled by the internals of the engine.
But I see what you mean.
>
> | 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.
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. Damn, if only I could say this right...
> 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.
"this" = what it means to conform to the SAM, how conformance is
verified or non-conformance detected.
>
> | 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.
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' ?
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?
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?
Jan
P.S. Thanks for the in-depth answers, they help a lot.
>
> --
> Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50 <URL: http://www.garshol.priv.no >
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
--
Jan Algermissen http://www.topicmapping.com
Consultant & Programmer http://www.gooseworks.org