OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] TMs & XTM [Was: skills to create topic maps]



* Lars Marius Garshol
| 
| It isn't. It's possible to do XTM work with XSLT, but my XSLT skills
| are not good enough to do merging correctly and still keep the XSLT
| at a manageable level of complexity.

* Tony Coates
| 
| Oh, let me be clear, the one thing I am not planning to try and do
| is merging in XSL-T.  It may not be impossible, but life is too
| short ...

I didn't think you were, but I'm a bit concerned that we seem to be in
a kind of "let's all invent the wheel" situation, where everyone
writes XTM-to-HTML processing solutions that implement the bits of XTM
they need, and nobody really produces anything that works really well
or allows them to make full use of the power of topic maps.

To me it seems that this is a symptom that shows us that we're missing
something, and it sounds like what we're missing is XSLT-for-topic
maps, something that would allow people to declaratively define
XTM-to-HTML transformations using an XML syntax. With good
implementations they'd be able to do their publishing on the
command-line or in a web server. Ontopia has a proprietary solution
for this, Empolis has another, and everybody else seems to be stuck
with half-baked XSLT solutions.

The reason I keep calling the XSLT-based solutions half-baked is that
to do things like reification, merging (which we really *do* need),
and scope filtering in XSLT is so hard that nobody's going to do it.
Which again means that we end up not making full use of topic maps,
which is to nobody's advantage. XSLT is good for XML, it's not good
for topic maps. A similar standard for topic maps would be enormously
much more useful.

We could solve this by making a standard for this, based on TMQL, but
that would mean waiting for quite a while. So what should we do?

| However, I do want to be able to take an exported topic map in XTM
| (which I will then assume is already fully merged) 

And since you wrote it you can safely make that assumption. But it
would be better if you didn't have to.

| You would think this should be reasonably easy, but I find that
| different tools have amazingly different ways of encoding the same
| topic map using XTM.  It's not that any of these ways is wrong, but
| it does make it hard to use standard XML tools.

I think you have this problem because you're using the wrong tools,
not because of any problem with topic maps. To output an HTML <ul>
list of all operas in a topic map, using their Italian names, sorted
by those names, is about 10 lines using our XML language. (If you want
the instances of all subclasses of opera as well that's two more
lines.) And that does merging for you without your even noticing. The
equivalent in XSLT is just not possible, and even in your limited case
using XSLT is bound to require a lot more than 10/12 lines.
 
We need to stop using XSLT and start using something better. And the
solution is not for everybody to buy Ontopia's software (even though
that would be very nice for us in the short term).

--Lars M.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC