[sc34wg3] SAM issue: sam-conformance

[Marc de Graauw]

Lars Marius Garshol:

| The conformance clause of XTM I think should say that a document
| conforms when it is valid according to the normative schema and can be
| deserialized into a SAM instance without triggering errors
| (XTM-specific errors or general SAM errors). Note that here the
| syntaxes normatively reference the SAM, but it is only the conformance
| clauses in the XTM documents that come into play.

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. The semantics of
what it means to be a Topic Map are stored in the definitions of the SAM. So
stuff such as "A base name is a name or label for a subject, expressed as a
string. That is, it is something that identifies the subject... etc."
(http://www.isotopicmaps.org/sam/sam-model/#sect-topic-name) should be
normative, not just informative. 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).

| As for implementations, I think they should be said to conform when
| they can do an XTM1 -> SAM -> XTM2 roundtrip where XTM1 and XTM2
| deserialize to logically equivalent SAM instances. SAM will have to
| specify exactly what this means by describing a comparison procedure.
|
| This means that if your tool can import XTM without being able to
| roundtrip it that tool does not conform to XTM. Similarly, if your
| tool can export conformant XTM without being able to do general
| roundtripping it does not conform. (This may be perfectly OK. The tool
| may be a genealogical research tool. All XTM will be saying is that it
| is not a conforming XTM implementation.)

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

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?

| Note that if you look at the Japanese NB comments on N0396 (sent to
| Sara late last night) they say that
|
|   "Conformance per se is not usually part of a formal data model and
|   should be removed from this part of the standard. A conformance
|   clause is required for ISO 13250, but it needs to be included as
|   either a separate part or in some other part to be decided by the
|   committee."
|
| This makes perfect sense to me, for the reasons given above, and it
| would indeed surprise me to find a data model that has a conformance
| section.

If the SAM were just a data model, I would agree. But in its definitions the
SAM contains a lot of semantics which provide the interpretation of the
underlying data model.

Marc