[sc34wg3] CTM: The arguments for standardization

[Lars Marius Garshol]

* Kal Ahmed
| 
| I'm broadly in favour of developing a common compact syntax for
| topic maps. To be honest, I don't really see the need for it to go
| through an ISO process, but thats another story.

I used to feel the same way. Doing CTM in ISO has been discussed on
and off for a couple of years, but I never felt it belonged in ISO.
However, now that I realize CTM is just a subset of TMQL update things
are rather different. We need the syntaxes to be coherent, and so CTM
needs to happen now, rather than after we've done TMQL-1/TMCL and used
up all the delimiters for the wrong things. All the other reasons are
just additional benefits, and perhaps my previous email should have
left those out, to make this clearer.

| 1) If TMQL does not support update using XTM, will that alienate
| those users who prefer XTM to a compact syntax ? How much effort
| would it be for TMQL to support both syntaxes for update operations?

Those are good questions, and I have to confess I don't fully know the
answers to them. Whether a non-XTM syntax for additions will alienate
users is difficult to answer because these users will already be
working inside a non-XML syntax (TMQL). Most likely something like

  INSERT <topic id="foo">...</topic>

is one thing, but TMQL also has topic map constructors for producing
topic map output, and quite possibly also TM->TM transforms, which
means CTM gets mixed quite deeply into TMQL. So I don't really know;
those users who prefer writing their topic maps in XTM might be able
to help us here.

As for the effort in making TMQL support both: I think for the simple
INSERT case it will be pretty straightforward. For the more complex
case of topic map output construction I'm not sure. We might be able
to get away with using the XML construction and then having a mode to
interpret XTM output as topic map information.
 
| 2) I am assuming that your statement that:
| 
| "implementor who wants to minimize the investment would probably do
| well to implement CTM and drop XTM"
| 
| is a bit of rhetoric rather than a serious suggestion from the
| editor of the XTM standard.

It *was* rhetoric, certainly, but not entirely vacuous. The point was
that CTM is likely to be quite easy to implement, and almost certainly
easier than XTM. Of course, I *don't* think an implementor who
implements only CTM will be well served by doing so, and I probably
should have made that clear.

| Surely if an implementor wants to support ISO 13250, then the
| implementor MUST support XTM. After all, this is all about
| information interchange and I think it would be highly damaging if
| you could claim to be a conformant topic map application without
| supporting import and export of XTM. So my question is will ISO be
| recommending one syntax and deprecating the other for interchange ?

That's another good point. Realistically, I think ISO's influence on
what people do is going to be limited[1], but at the same time I think
you are right that there should be some sort of "official policy" on
this. My suggestion would be that XTM is kept as the official
interchange syntax, and that CTM is relegated to a kind of "supporting
role", as "nice syntax for crazy techies who use Emacs". I don't think
any prospective CTM user is going to be put off by that (LTM/AsTMa=
users certainly aren't), and if some are that's not really a problem.

As for the "MUST" (which has to be "shall" in ISO-land, BTW :) I'm not
sure what machinery ISO makes available to us for that. If the
implementor says "I implement ISO 13250-6, and only -6" I'm not sure
what anyone can do about that. If someone knows, or has a suggestion,
I'm more than ready to hear it.

[1] There's already one "LTM implementation" out there that is just
    that, an LTM-based topic map implementation. No XTM support
    whatsoever.

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