[sc34wg3] Issue (term-tm-processor)

[Mary Nishikawa]

At 12:26 PM 8/26/2002 -0400, Patrick Durusau wrote:
>Mary,
>
>Mary Nishikawa wrote:
>
><snip>
>
>>
>>>Only an application would be concerned with serialization (serialization
>>>is the convesion of topic map syntax (from however it is held) into a
>>>byte stream and deserialization is the reverse of that process).
>>
>>
>>Will a Top Map Application be defined elsewhere, or will this be=20
>>implementation specific?
>
>Let me see if an example helps (I am actually writing something for=20
>internal consumption so let me try it here first!) (short answer: topic=20
>map applications are implementation specific, read on for fuller example.)
></snip>

Partick, Thanks for your lengthy example.  I think that I didn't say=20
clearly enough what I was asking.

Here is what we have in the SAM now:
---------------------
The process of exporting topic map information from an implementation's=20
internal representation to an instance of a topic map syntax is known as=20
serialization. The opposite process, that of building such a representation=
=20
from information encoded using a topic map syntax, is known as=20
deserialization. Conforming specifications of topic map syntaxes must=20
define both processes in terms of the model specified in this specification.

A topic map processor is any software module that can process topic map=20
information in conformance with this standard. It is assumed that the topic=
=20
map processor does its work on behalf of another module known as the topic=
=20
map application. This international standard assumes that a topic map=20
processor will do both serialization and deserialization on behalf of the=20
application, and that the processor will manage the topic map information=20
on behalf of the application.

Issue (term-tm-processor):
Do the definitions of the terms 'topic map processor' and 'topic map=20
applications' have unwanted consequences for what software architectures=20
can be conforming implementations of this standard?
------------------

We all agreed that the answer to this was "yes." We agreed to define the=20
term "topic map processor", but not define "topic map application."  Is=20
this correct? If we do not define "topic map application," then we do not=20
need to discuss this serialization and deserialization business.

I want to confirm that we agreed not to define "topic map application" in=20
the SAM. Is this correct? If it is then, don't we still need to possibly=20
define what an XTM application is, in general terms at least in the SAM?

I think that there is some ambiguity in how  "application" and "processor"=
=20
are used in the XTM spec.

  We have  three terms, "XTM processor" and  "XTM processor application"=20
and  "XTM application" in the XTM spec.  We have terms such as=20
"application-specific processing" all over the place.


In the XTM spec, we have this:
--------------------
An XTM application is any software module that:
=B7       interprets a <topicMap> element, producing a processed topic map=
 as=20
defined and described in
=B7       Annex F: XTM Processing Requirements.
An XTM application conforms to the XTM 1.0 Specification if and only if all=
=20
of the following conditions are satisfied:
=B7       All of the constraints specified in
=B7       Annex F: XTM Processing Requirements regarding the handling of=
 each=20
XTM element and attribute are honored by the XTM application.
=B7       All Reportable XTM Errors are detected, and the XTM application is=
=20
capable of reporting all of them.
=B7       All Merging Rules and other Rules specified in
=B7       Annex F: XTM Processing Requirements are honored by the XTM=20
application.
----------------------

Best regards,
Mary