[sc34wg3] XLink support in XTM

Lars Marius Garshol larsga at ontopia.net
Tue Mar 21 19:26:05 EST 2006


* Murray Altheim
>
> No value? You get a linking model, semantics and syntax.

Yes, but do we actually want any of that? It may sound like a  
rhetorical question, but it's not. XTM is the transport syntax for  
TMDM instances. Does it really need a linking model? If so, what  
would we use the linking model for? (Maybe I just don't understand  
what you mean by "linking model".)

> If you drop XLink the standard will have to describe those three  
> things

We have to anyway. The XLink model is not the one we use, so we have  
to map the XLink elements to TMDM without being able to *use* any of  
the XLink model or semantics. The 2005-12-16 draft doesn't use XLink,  
the 2005-10-28 draft does. The 2005-12-16 one is simpler, because it  
doesn't have to deal with XLink, but both equally fully specify  
processing.

> As for relating to two standards, that's a silly argument.
> We're already relating to many standards -- the idea that XLink is
> overhead is certainly not borne out in implementations, and if the
> amount of space in the standard to make reference to XLink bothers
> you, there's a lot more important things to be bothered over.

I didn't say anything about implementations. The overhead is  
primarily that it makes the standard more complicated. Of course, you  
are right that the overhead is not huge, but unless there are  
compensating benefits, what's the point?

> Integrating XTM with other XML markup languages is enormously  
> simplified if each one uses XLink rather than creating their own  
> proprietary linking language, which is what you're proposing. And  
> with XTM 2.0 permitting arbitrary XML markup, I would think the  
> argument for XLink would be even stronger now than in 2000.

I can't see that XLink simplifies anything in this regard. Could you  
explain what it is that becomes simpler, exactly?

> As for ease of typing the syntax, that never was a priority, nor  
> should
> it be. Nobody in their right mind would spend much time typing XTM; it
> wasn't meant as an authoring syntax.

I know, and I agree.

> This wasn't a big deal in 2000, nor is it now. You seem to like RDF,
> whose community thinks nothing of having a dozen namespaces in one
> document. We have two in XTM, one for the Topic Map semantics, one
> for the XML-based linking semantics. That seems pretty sensible to me.

It's not outrageous to have two namespaces, but it's better to have  
just one, if we can. And as far as I can tell, we can have just one,  
without losing anything.

> It's a default attribute -- big deal.

It's a default attribute that in most documents simply will not be  
there, and those documents will not be valid XLink documents, so  
whatever benefits XLink might bring to XTM these documents won't get.

> Simplifying the syntax at the expense of dropping the linking  
> semantics
> seems to assume that the corresponding language ambiguity is  
> acceptable.

We have to specify these semantics in detail ourselves, regardless of  
whether we use XLink or not. The only difference is whether people  
have to relate to what we write + what is in XLink, or whether they  
can relate only to what we write. Clearly the latter is simpler and  
easier for all concerned.

> I believe I was the one who argued most vociferously for XLink, so  
> I'll
> take the blame.

We can share it. There's plenty to go round.

> As for a lot of things that were good ideas in 2000, you might  
> remember that there are some of us who think a great number of the  
> decisions you're making in altering XTM from 1.0 to 2.0 to be in  
> error.

Well. I'm happy to take input on design decisions in the latest XTM  
draft that people feel are poor. I can't promise to agree, though.

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




More information about the sc34wg3 mailing list