[sc34wg3] CTM: The arguments for standardization

[Kal Ahmed]

Lars Marius,

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. Accepting that this is to be done 
by WG3 anyway, I have a couple of issues that perhaps you can address.

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 ?

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. 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 ? If not, how will 
consistent interchange between implementations be maintained ?

Cheers,

Kal

Lars Marius Garshol wrote:

>It seems clear that there are still people on this list who don't
>believe it's necessarily a good idea to standardize CTM. I also get
>the impression that not all of the arguments for have been understood,
>so here is another attempt to explain the rationale.
>
>
>Although CTM is an alternative to XTM, the fact that there are people
>who prefer editing in XTM to syntaxes like CTM makes no difference.
>The point is that there are lots of people who prefer a syntax like
>CTM over XTM, and these people already use one of the two non-standard
>syntaxes (LTM/AsTMa=). So here, already, we have a reason to
>standardize: people are using multiple, competing proprietary
>solutions in this area. No matter what we may think of such syntaxes,
>the only way to change this is to create a standard alternative. And
>that's what CTM is about.
>
>
>We are creating TMQL, which at one point will have a part 2 (updates)
>where people can add new topic map data to a topic map. For this to be
>possible there has to be a syntax for topic map data that fits inside
>TMQL. The idea is that we'll create this syntax now, call it CTM, and
>solve the problem above together with this one at a single stroke.
>
>
>This has the benefit that we can make sure that the three syntaxes
>(CTM, TMQL, and TMCL) stay in sync. We want to ensure that scope, for
>example, is expressed with the same delimiter in all of these
>syntaxes. The best way to do that is to start with CTM now, so that we
>can do all three in parallel.
>
>
>Some people have expressed the reservation that CTM is "only for
>techies", and that therefore it shouldn't be standardized. There are
>several reasons why this doesn't hold:
>
>  a) We're not doing this because "techies" want this; we're doing it
>     because we need it for TMQL.
>
>  b) An *additional* argument is that technical things like topic maps
>     generally catch on with technically minded people first, and a
>     large subset of those people would prefer a syntax like CTM over
>     XTM.
>
>
>As was pointed out by Jim, most papers about topic maps, and a large
>number of the emails about it, too, need to be able to show topic map
>examples. XTM is sufficiently verbose that a couple of tiny examples
>may be enough to bring you over the page limit for your paper (or
>exhaust the patience of the readers of your email). Today I often use
>LTM for this, Robert uses AsTMa=, and many other people use XTM.  It
>would be a major improvement if we could reduce the number of syntaxes
>used for this to one (CTM), which it would then be much more
>reasonable to expect people to at least be able to read.
>
>
>One objection has been that such a syntax means a higher bar for
>implementors, and more work. It does mean more work if anyone wants to
>implement all the parts of ISO 13250, but it's not required to
>implement CTM, and an implementor who wants to minimize the investment
>would probably do well to implement CTM and drop XTM.  (Note that
>having two syntaxes is unlikely to be a problem; converting from the
>one to the other with a tool that supports both is going to be
>trivial, provided we get the design right.)
>
>
>The objection that CTM means more effort for the committee likewise
>doesn't hold, because we will have to do this as part of TMQL anyway.
>The only difference is that we are moving it forward in time, to be
>able to get rid of LTM and AsTMa= and to make sure we get three
>consistent syntaxes.
>
>
>I hope this makes it clearer why the proponents of CTM want it. I also
>hope it makes it clear that the "I think editing XTM is OK"-argument
>is not an argument against standardizing CTM.
>
>  
>