[topicmapmail] stupid question?

[Lars Marius Garshol]

* alexander johannesen
| 
| I do understand that we use the right tool for the job, but in a
| setup where most - if not all - work is done through XSLT, I don't
| really see bringing a new technology and platform into it to be a
| *better* solution. 

Perhaps you have to try it to see how much better it is. In fact, I
don't see how XSLT is any different from a transformation language
specially designed for topic maps. How did bringing a new technology
and platform (XSLT) help you with XML, when you could have used some
scripting language instead?

| In an ideal world you choose whatever suits the problem, but in a
| lot in my cases - especially working with people who can't / refuse
| to use anything else - I must keep the development environment as
| clean as possible. Convincing people to use anything but their
| favourite tool is like convincing people that Topic Maps is a better
| approach than whatever they're doing now; it takes time.

That sounds like a sensible reason to me.
 
| Having said all that, I'm blessed with the fact that the XSLT-parser
| is written in Python, so to add useful tools to *that* environment
| seems like the right thing to do. Extensions to XSLT is not bad per
| se, just less portable and slightly more complicated to set up.

Writing extensions to 4XSLT is very easy. See my book[1] for examples
of how to do it.
 
| If you on the other hand have alternative good solutions to TM
| implementation into a fully XSLT-environment, then I'd be most happy
| to hear them. The only thing that springs to mind is tools that
| convert XTM into structural XML for further XSLT processing. Any
| such tool that comes to mind, and maybe a standard for (somewhat
| more) structural representation of TM's?

I know empolis does something like this in K42, but I am not familiar
with the details. Personally I don't believe in this approach, and
leave it for other people to try out.

On the other hand, something like this could be cooked up in a couple
of hours by someone with the right tools. Basically, you could take
the Canonical XTM[2] proposal, remove the ordering rules, and produce
an application that did XTM -> normalized XTM.
 
| I also agree with the problems of XML and identity. One thing that
| I'd like to stress, though, is wheter XSLT is used in a dynamic or
| static fashion, and as my work is mostly done in static frameworks
| for building larger prototypes I find that XSLT gives me what I need
| to perform this job in a simple and good fashion. Of course, and
| this might be *the* main point on your side, is that I use rather
| simplistic TM's with only a few scope-rules and set associations. I
| guess I wouldn't dare to go full on with TM in XSLT, so I'll just
| keep quiet now. :)

It seems we pretty much agree, then. :-)

If you need to make a quick-and-dirty prototype using a simple topic
map and have no TM-specific tools to hand I see no reason why you
can't follow the approach that you have taken. For full-scale
projects, however...
 
* Lars Marius Garshol
|
| Jonathan Robie tried to show how XQuery function libraries might
| help, but I wasn't convinced.
 
* alexander johannesen
|
| Not that I'm out to convince you, but what does it take to convince
| you?

A demonstration that working with arbitrary topic map structures (ie:
non-normalized) with XQuery/XSLT can be as easy as (or even nearly as
easy as) with solutions specially designed for topic maps. They would
of course also have to have comparable performance on larger data
sets.

With specialized languages finding all classes that have no superclass
and sorting them alphabetically by their sort name variants, then
outputting them as an HTML list is doable in 10-15 lines. This
regardless of the syntax of the source topic map or how it was
represented in terms of references and required merges. (In our
RDBMS implementation, this maps to just a couple of SQL queries;
in-memory it is very fast.)

I don't expect XSLT/XQuery to be able to do this, and I don't see any
reason why they should. They were designed for other things, and those
things they do very well.

[1] <URL: http://www.garshol.priv.no/download/text/ph1/ >
[2] <URL: http://www.ontopia.net/topicmaps/materials/cxtm.html >

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