Re: [TM4J-users] TM4J project web site & XTM (was RE: new member)

[Kal A. <ka...@te...>]

At 14:21 21/11/2001 +0100, Florian Haas wrote:
>[me]
> > >Actually generating the site from XTM exclusively is, I think, beyond our
> > >possibilities at the moment. For now, we don't even have a set of XSLT
> > >stylesheets we can use in order to transform everything into HTML. Thomas
> > >and I are thinking about taking care of that eventually, but for now we
> > have
> > >to acknowledge that what we've got is quite little. Unless of course you,
> > >Kal, talk to your friends at Ontopia and they give away the Omnigator for
> > >free! :-)
>
>[Kal]
> > That would be an idea - though we would need somewhere to host it too -
> > Sourceforge don't support JSP on their hosts :-( As we reach the point of
> > needing a dynamically generated site from XTM, it would be nice to do it
> > with TM4J tools anyway - and I think that within that time frame some
> > alternative hosting solution may come up...Especially if my consulting
> > takes off ;-)
>
>Actually, the thing about using Omnigator was supposed to be a joke on my
>part. :-) Not that I don't like it -- in fact I love it and I think the
>Ontopians have put together an awesome piece of work -- but there are two main
>reasons why I don't think it would be too good an idea to use it for the 
>TM4J web
>site. Feel free to correct me if any of these happen to be based on false
>assumptions.
>
>1. TM4J is free, Omnigator isn't.
>2. Omnigator is JSP-centered, rather than XSLT-centered.
>
>While the latter isn't a problem in and of itself, I do believe it would be
>a good idea to keep TM4J as deeply rooted in standards or de facto standards
>as possible. We already use Xerces, Jakarta-regexp, Xalan etc. ... wouldn't
>it be a better idea to use XSLT (which is a W3C recommendation), XHTML (which
>is a W3C recommendation), and XTM (which should be a W3C recommendation :-) )
>along with the corresponding Apache project packages, which everyone uses,
>rather than using a from-scratch JSP implementation? I think the former is
>more in line with the open-source nature of TM4J.

Firstly, thanks for raising this Florian. This is definitely a discussion 
worth having!

I don't think that using JSP is necessarily against open-source principals. 
After all, the (IMHO) best servlet container is Tomcat, and thats open 
source... I would be interested to see how far an XSLT-only implementation 
could get. I know that at least one consultant has successfully used XSLT 
as a means of publishing topic maps. Perhaps we should look at developing 
some basic stylesheets with useful "utility" templates (e.g. templates to 
extract names from topics or to determine if a topic is of a particular 
type or class).

But I also know that Ontopia use JSP because it gives more flexibility - at 
the expense of requiring Java code. Perhaps there is a 'middle way' here - 
and that was one of my reasons for looking at Velocity - which gives a 
scripting language with tight integration to Java code - so the TM4J 
offering could be the script components that allows people to quickly build 
websites from XTM files.

There are lots of options here:

XSLT only - good for static websites. May be restricted in functionality
JSP only  -  good for dynamic websites. Full access to API functionality 
but requires Java coding skills
JSP with XSLT - good for dynamic websites Full access to API. Styling could 
be provided through XSLT without requiring Java coding.
JSP with Velocity - good for dynamic and static websistes. Potentially full 
access to API (may require an interface layer between the Java API and 
Velocity - though that should be quite thin). Site developers can work 
without needing to know any Java - although some functionality might 
require quite a lot of scripting
JSP with Velocity and XSLT - Dynamic and static websites. Site developers 
don't need to know any Java. Velocity could be used to generate XML which 
is styled with XSLT.

I like the last of these options best because it divides responsibility 3 ways:

1) Java coder - provides library functions for complex operations which are 
then exposed as simple scripting functions
2) Site content coder - generates XML documents using parameters received 
from the web request. This is all done in Velocity scripting language
3) Site designer - creates XSLT stylesheets to render the XML documents as 
(X)HTML with or without CSS.

Best of all, all of this can be built with open-source software and all we 
are really missing from this jigsaw is the Velocity integration!

Comments welcome!

Cheers,

Kal