[sc34wg3] Aug 3 meeting: Issue (term-tm-processor), Issue (xtm-implicit-constraints):

Mary Nishikawa sc34wg3@isotopicmaps.org
Sat, 24 Aug 2002 13:39:53 +0900


Hi,

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.


Issue (term-tm-processor):

"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?

$B$I$s$J%=%U%H%&%(%"!&%"!<%-%F%/%A%c$,$3$NI8=`$N9g$o$;$k<B;\$G$"$k$3$H$,$G$-$k(B 
$B8@MU$NOCBjCO?^$N%W%m%;%C%5!<$H(B $BOCBjCO?^$N1~MQ$NDj5A$K$N$?$a$NM_$7$/$J$$7k2L$,(B 
$B$"$k$+(B.

$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.

***Decision:$B!!7hDj(B
  Lars is re-working the prose.

Steve N. We don't care about serialization,  not what a topic map processor does.

***Decision: agreed.

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?

Issue (xtm-implicit-constraints):

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?


Thanks,
Mary