[sc34wg3] Aug 3 meeting: Issue (term-tm-processor), Issue ( xtm-implicit-constraints):
Mon, 26 Aug 2002 12:26:03 -0400
Mary Nishikawa wrote:
>> 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
> implementation specific?
Let me see if an example helps (I am actually writing something for
internal consumption so let me try it here first!) (short answer: topic
map applications are implementation specific, read on for fuller example.)
Imagine we are developing a standard processing model for word
processors. They must:
1. Store texts.
2. Display texts.
3. Allow users to enter text from a keyboard.
4. Print texts.
Those are all things we have defined as things that an application must
do to be considered a word processor.
Now we going looking for word processors: Microsoft Word? Yes. Emacs?
Yes. vi? Yes. Asteroids? No.
We only defined what the application had to do to qualify as a word
processor, nothing about how it actually went about those tasks.
What is being defined in the SAM is very similar and will be the
benchmark by which something is considered a topic map application or
not. (Actually the SAM is defining operations on and the results of
operations on a topic map so that each topic map application will reach
the same result, but essentially the principle is the same.)
Does that help?
(If anyone has a better example, please post to the list.)
> Sorry for asking all of these questions. I anticipate that I will be
> asked questions such as these at our local meeting, so I want to be
>> > 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.
> This is clear. Thanks Patrick.
> Best regards,
> sc34wg3 mailing list
Director of Research and Development
Society of Biblical Literature