[topicmapmail] stupid question?

[Lars Marius Garshol]

* W. Eliot Kimber
| 
| I agree with Lars: 

Finally... :-)

| While it is possible to use XSLT to process XTM documents, there are a
| number of hard things that it is difficult at best to do in XSLT,
| especially dealing with topic merging and scopes. 

Exactly. 

Addressing topics and interpreting topic references correctly becomes
hard in XSLT, though by making your XTM follow certain conventions you
can alleviate that. Of course, that will leave many topic maps outside
your reach. 

(People tend to think of merging as a process that's only applied to
entire topic maps, which is wrong. Merging and loading a single topic
map are *the*same* operation! Merging also happens within topic maps,
given the way the serialization syntax is designed.)

Also, name selection for presentation, as well as matching of scope
when following occurrences and associations, is difficult, partly for
the same reason, and partly because set matching in XSLT is not a
fundamental operation.

There's probably more problems, but not having tried it I can't really
point to them.

Oh, another thing that is likely to be very difficult is getting
sorting right, especially the interaction of sorting with scope and
also with sort name identification.

| It would also be difficult to prove that a given XSLT style sheet
| conforms to the Topic Map reference model, simply because there
| would be no way to instantiate the implicit abstract topic map the
| XSLT script is operating on (which is not the same thing as saying
| you couldn't write an XSLT script to generate some stringified topic
| map reference model instance, just that that script couldn't be the
| same one that implements your business logic because XSLT provides
| no way to build an accessible data model in memory as you can in say
| Java or Python or C++).

Exactly. An XSLT library might have a canonicalization implementation
built on top of it that, when we have a test suite, would prove that
the approach is at least workable, but canonicalization in XSLT would
probably be near-impossible.
 
| I think that if you need a no-license-cost solution then using TM4J,
| as an example, is an excellent way to go--it handles all the scoping
| and merging for you and provides a reasonably easy-to-use API for
| accessing the abstract topic map.

I would agree, though it should be noted that doing web publishing by
topic map API programming is not much easier than XSLT, even if it
lets you handle more topic maps. 

My impression is that the Perl XTM module is also quite good, but I've
never used it (hey, it's Perl! :) so I can't tell for certain.

ZTM is not as complete as TM4J, but it has the advantage that it has a
simple editing interface and that the API+Zope integration gives you a
reasonable way to publish the topic maps.

| If you can do DOM programming you can use TM4J.

You mean, if you have a strong stomach that is not upset by excessive
ugliness? :)

| It would also be possible to integrate something like TM4J with an
| XSLT processor to provide utility functions that do merging and
| handle scopes and association role membershipo, although I'm not
| sure off the top of my head exactly how that would work (your style
| sheet would still need to be prepared to deal with the possibility
| of merging in some way if you're not process pre-merged and
| normalized XTM instances).

What you could do is what Jonathan Robie and I propose in his "The
Syntactic Web" paper: 'cook' the topic map into normalized form first.
Just importing into a topic map engine and then exporting back out is
basically all you need. So you can do this with the Omnigator or write
a simple normalizer on top of TM4J. 

| If the XML community had a general API for mapping arbitrary data
| structures to a common data model that could then be processed by
| XSLT, it would be less of an issue--you could use any TM engine to
| express the abstract topic map in this data model and then it would
| be available for XSLT processing in a much easier-to-process form
| that wouldn't require the generation of intermediate XML instances

Yes. It would still suck, but it would suck less.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >