[sc34wg3] Aug 3 meeting: Issue (term-tm-processor),
Sat, 24 Aug 2002 13:39:53 +0900
I am reporting on the WG3 meetings to the Japan Delegation on Tuesday and I
need some help to clarify some of the issues and decisions that were made.
I am going through Patrick's notes (really excellent, thanks Patrick).
Also, Thanks for all the replys on the definition of "assertion." I will
present the feedback I got here and we will decide at our meeting. I will
leave the Japanese here for Naito-san and Tony. If anyone else would like
to view the Japanese you need to install Japanese IME and you can view your
mail from the Netscape Communicator Mail. I am doing a machine translation
and fixing anything that looks strange.
"A topic map processor is any software module that can process topic map
information in conformance with this standard. It is assumed that the topic
map processor does its work on behalf of another module known as the topic
map application. This international standard assumes that a topic map
processor will do both serialization and deserialization on behalf of the
application, and that the processor will manage the topic map information
on behalf of the application."
Do the definitions of the terms $B!N(Btopic map processor$B!O(B and $B!N(Btopic map
applications$B!O(B have unwanted consequences for what software architectures
can be conforming implementations of this standard?
$BOCBjCO?^$N%W%m%;%C%5!<!!(Btopic map processor
$BOCBj?^$N1~MQ(B topic map application -- wadaichizu no ouyou
$BI8=`(B standard -- hyoujun
$BDj5A(B a definition
$BM_$7$/$J$$7k2L(B $B!!!!(Bunwanted consequences
Michel: Applications (not defined), use the topic map processor.
Lars is re-working the prose.
Steve N. We don't care about serialization, not what a topic map processor does.
Here are my questions:
It seems to me that we will define what the topic map processor does. A
topic map application is not defined, but we will/or will not define it? I
don't understand Steve's comment. What does a topic map processor do? It is
not concerned with serialization?
The XTM DTD contains a number of implicit constraints, such as that an
addressable subject may not be used as a theme or a type. Should these
constraints be mirrored in the SAM?
SteveN: lets make SAM as clean as we can.
Lars, no other way around. XTM DTD looks as if certain things are
disallowed but they aren't.
***Decision: Not restricted, the implied constraints in the DTD.
OK, I understand this to mean that even though these are implied and are
not actual contraints in the DTD we cannot assume that they are in fact
are. This will be taken care of by TMCL later on?