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

[Lars Marius Garshol]

* Mary Nishikawa
|
| [...] 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.

Actually, I can view it just fine in Gnus without installing anything.
Modern mail clients should be able to display this without
difficulties, and without requiring anything other than fonts to be
installed. 

| Issue (term-tm-processor):
| [...]
| 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?

That is correct. The SAM part of the standard as well as the XTM and
HyTM syntax specifications are all about constraining what topic map
processors (or topic map implementations, if you like) do. 

What topic map applications do, however, is what end users decide, and
the standard does not concern itself with what they do, except
indirectly by constraining the processors used by the applications.

This issue is really about Sam's concern that these definitions might
outlaw topic map applications that are not separated into a processor
and an application, and that we probably didn't want to do that.

I don't understand SRN's comment either, to be honest. Either Patrick
didn't get it right, or context is needed to understand what SRN
meant, or he just said something nonsensical. I don't know which of
these is the case.

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

What it really means is that the XTM DTD attempts to constrain things
such as disallowing the use of topics representing resources (topic
items having a [subject address]) from being used as scoping topics.
It does this by disallowing <resourceRef> elements inside the <scope>
element, but that is easy to get around.

This decision means that the SAM model will not attempt to retain all
of these implicit constraints, which basically means that we as a
community disagree with what we did in XTM 1.0. There are no backwards
compatibility issues here, so we are free to do that.

| This will be taken care of by TMCL later on?

Not really. TMCL is about specifying application-specific constraints,
whereas the SAM constraints are constraints that must apply to all
topic maps because of how topic maps work.

I hope this helps.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >