[sc34wg3] XTM 1.1 issues

[Lars Heuer]

Hi Murray,

[...]
> Since you guys are in charge of the process and feel it within
> your rights and duty to make such substantive changes to XTM,
> such that to my eyes at least it doesn't look or act remotely=20
> like the syntax of the current markup language, why not call=20
> it something else? You've plainly got a much different agenda
[...]

Well, like everything else, XTM evolves.
From=20my point of view it would have been a mistake to change the
namespace but not to take the chance to clean up the syntax.
Either the TM community has to keep the XTM 1.0 namespace or take the
chance to make XTM consistent to TMDM terminology.
I think breaking backwards compatibility implies the chance to make
XTM ready for the future.
Because of the backwards compatiblity break I am much in favour to
rename XTM 1.1 into XTM 2.0, but it is just a number.

Anyway, I think it is a failure to keep the mergeMap element in the
XTM 1.1. This might belong to the upcoming CTM syntax which is
designed for _authoring_ topic maps, while XTM should be designed for
_interchanging_ topic maps (XTM should be readable by humans, though).

Due to the lack of the specialized Topic Maps authoring language
it seems that mergeMap has to stay. IMO this mergeMap "feature" is
very artificial. If you receive a PDF and the Acrobat Reader tells
you, "Well, I've to fetch the page 'X' from location 'A' and page 'Y'
from location 'B'" it would be very strange. The PDF is a complete
document and a XTM should be a complete topic map.
The sender should be responsible to keep everything in place and send
the topic map (or fragments of a topic map or a number of merged topic
maps) in one file.

> I think it's time to call your duck a dog, if it barks instead
> of quacks.

:)
It's still a topic map interchange syntax.


Best regards,
Lars
--=20
http://semagia.com