[sc34wg3] A plea for CTM and a request for more input on requirements and evaluation

[Lars Marius Garshol]

* Kal Ahmed
| 
| (h) -- I think this should be interpreted as meaning that it should
| be possible to format CTM (with whitespace and line-separator
| characters) to make it easy to read. Its always possible to write
| hard-to-read code...even in Python ;-)

I think that's an additional requirement. 

I guess what you're unhappy with is that "CTM must be easy to read" is
a requirement that isn't absolute in the sense that it will either
fail or succeed, and that people can be relied on to agree on what it
really means.

I guess that's a valid objection, and that perhaps it's best to divide
this list in two: goals (of which (h) would be one) and requirements.
 
| (q) -- I don't think this should be a requirement for CTM - I think
| it would more be a requirements that any graphical notation should
| cover TMDM. Then CTM "integration" with a graphical notation would
| be a logical conclusion.

I tend to agree.
 
| (v) -- XTM -> TMDM -> CTM and back is not necessarily a lossless
| transformation. For example XTM -> TMDM loses information about the
| grouping of topic references under association roles and the nesting
| of variant names.

I agree. I think (t) already covers this. If we want to tighten (t) we
can add a final -> TMDM at the end and require the two TMDM instances
to be equal.
 
| Two more requirements that I think you should consider:
| 
| 1) CTM must support the creation of modular topic maps with minimal
|    "import" mechanism. Something like LTM's INCLUDE directive.
| 
| 2) CTM must support the inclusion of author comments within a CTM
|    file, and support the "commenting-out" of CTM constructs.

Agreed.

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