[sc34wg3] SAM issue: sam-conformance

[Lars Marius Garshol]

* Marc de Graauw
| 
| The problem here is conformance is only defined on a syntactical
| level. In the SAM much work has been done on clarifying basic TM
| concepts such as names, scopes, reification. As a result the new
| XTM-spec contains no information on the semantics of names,
| occurrences etc. 

That's true in the sense that this information is not physically
inside that document, but it normatively references the SAM, so that
when the XTM spec writes (in 2.11):

  "The occurrence element type is used to assign an occurrence to
  the topic defined by the parent element."

it uses the terms 'occurrence' and 'topic' with the meanings assigned
to them by the SAM, and section 3.12 connects this firmly up with the
SAM by saying:

  "The occurrence element causes an occurrence item to be created, and
  added to the [occurrences] property of the topic item created by the
  parent topic element."

So the SAM would be normative, and normatively referenced from
XTM/HyTM/..., it's just there will be no notion of conformance to the
SAM in isolation. You can only conform to the other parts, not to the
SAM itself (except indirectly, of course).

| So I believe the SAM should have some kind of conformance clause. If
| someone implements a would-be Topic Map engine which stores names in
| <occurrence> elements, and homepages in <baseName> elements we
| should be able to say they've made a mess and do not conform to the
| standard(s).

The question is how you can do this in a meaningful way. If they store
names in XTM elements we can hit them over the head with the XTM spec,
but if they deserialize <baseName> elements to an object of class
Occurrence and <occurrence> elements to the same class, but there's a
method 'int getType()' that returns 1 for base names and 2 for
occurrences, what do you do? Is that conformant or not? Is it
conformant if you take the 'getType()' method out? And so on.

To me it seems that conformance of the internal representation of a
topic map engine to the SAM is going to be something very subjective.
There is, however, one test we can make: whether the internal
representation can (in whatever way) be mapped to the SAM. The easiest
way to test that is to see whether they can successfully roundtrip XTM
back to XTM (or, which amounts to the same thing, XTM -> CXTM). If
they can, they must have some internal representation that is
equivalent to the SAM, and I don't know what more we can ask, really.

If you do think we should have a conformance clause I'd very much like
input on what you think it should look like. I don't think the one we
have now works. Documentation of SAM/API correspondence is not really
worth anything that I can see.

| [XTM]
| 
| I think it would be good do describe various levels of conformance:
| 1) round-tripping as described above
| 2) being able to export conformant XTM
| 
| The rationale is people might want to implement XTM-export and/or
| XTM-import interfaces in existing applications without building a
| complete TM engine (which can do round-tripping). And if they do,
| providing a stamp ("My App conforms to the XTM-export conformance
| clause") would help them state clearly what they've done.

I think the only way to conform in that regard is to say "we produce
conformant XTM". I can't really think of any other meaningful way to
express that. We could define an "exporter" conformance level that
means "we always produce conformant XTM", but I'm not sure that adds
any value.

| With your proposal one must either build a complete engine which
| conforms to the XTM specification, or claim no level of conformance
| at all. (I recently described in XML.COM
| http://www.xml.com/pub/a/2003/03/05/tmrdb.html how one could add
| XTM-exporters to relational databases. Though the very simple demo
| application described could not reasonably claim any conformance at
| all, the principle should be clear.)

Hmmmm. No, not really. You can claim to export correct XTM, and by
implication that your exporter is conformant.
 
| The third alternative
| 3) being able to import conformant XTM
| does not seem to make much sense. Would "importing" and sending the doc to
| the printer be conformant?

Not really. If you import XTM it implies that you are picking
information out of the XTM for your own use. There's not really much
sense in constraining this aspect of software, I think.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >