[sc34wg3] CTM: The arguments for standardization

[Kal Ahmed]

I agree with the need to do CTM for TMQL and I agree with your assertion 
that it makes sense to do CTM as a prelude to nailing down TMQL syntax. 
I guess that means I am in the "crazy techie" camp too ;-).

In terms of doing update with XTM, perhaps you can keep the QNames and 
just relax the constraints of the schema to allow partial specification 
of constructs. My feeling is that supporting XTM (in some form) in TMQL 
is not so much a question of getting all the goodness that flows from an 
XML syntax (that is clearly not going to happen with TMQL syntax!), but 
more of making it easy for people to write their TMQL  update queries. I 
hope that you will keep this as a goal for TMQL as you are developing 
the syntax for that (no sneaky using '<' and '>' as separators! ;-)

In terms of implementations and ISO conformance. I think that the ISO 
influence is going to be less on individual developers[*] and more on 
informed consumers. If ISO wavers in commitment to XTM then it could be 
taken as a signal to the buying community that they do not have the 
guarantee of a degree of vendor independence through standard 
interchange syntax. That wouldn't be good for anybody. So I agree with 
you that a policy statement is needed. If CTM is to be part of ISO 13250 
(I'm not sure if I missed the bit of the discussion about whether this 
is an ISO 13250 part or a separate standard), then my feeling is that 
the place to make this policy statement is up front in the part 1.

Cheers,

Kal

[*] especially in the open-source community where it is more a case of 
"here, this works for me"

Lars Marius Garshol wrote:

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