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

[Patrick Durusau]

Mary,

Hope the following helps:


Mary Nishikawa wrote:

> 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$,(B
> $B$G$-$k(B $B8@MU$NOCBjCO?^$N%W%m%;%C%5!<$H(B $BOCBjCO?^$N1~MQ$NDj5A$K$N$?$a$NM_(B
> $B$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?
>
Yes to defining a topic map processor, no to defining a topic map
application. The difference is that a topic map processor takes a topic
map (how that topic map came to be is deliberately undefined, we don't
speak of topic map authoring) and performs operations on it. Note that
the topic map processor is defined as processing "topic map information
in conformance with this standard." In other words, the standard will
define a set of operations on topic map information that if performed by
a bit of software, qualifies it as a topic map processor. Note that the
"how" of the operations, at least in an operational sense will not be
defined. Just if you have condition 1 and condition 2 in a topic map,
action (or non-action) #3 must result to qualify as a topic map
processor. (Odd way to speak admittedly but does get a level of
abstraction that allows for robust development.)

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

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

No, I read this to mean that constraints that were implied by DTD syntax
are not to be followed (because they really weren't meant as
constraints) by the SAM. Restrictions will no doubt be authorized by the
TMCL, but those will be on a principled basis and not implied by syntax.


Hope this helps!

Thanks for the undeserved compliment on the notes! Lars and I are
discussing ways to make them more effective for the next meeting.

Patrick

>
>
> Thanks,
> Mary
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu