tm4j-users

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

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

At 10:10 21/11/2001 +0100, Florian wrote:
>Hello.
>
>[Kal]
>| In terms of the website. I would really like the website to be designed
>| with the concepts of topic maps in mind. I think it would be
>| great to make
>| use of topic maps to generate the site - even if it is initially static
>| HTML pages, it would be good if the sources for those pages are linked
>| together not only with normal <href> links, but also are
>| organised within a
>| topic map which could then be used to automatically insert extra
>| navigation
>| links into the HTML. However, that is getting a little to advanced too
>| quickly.
>
>Agreed. :-) I have suggested similar ideas to Thomas, and as far as I recall
>I also once had a conversation with you about eventually using XTM as
>something like a CMS for the web site, and bringing everything alive with
>Tomcat, Velocity etc.

That should definitely be the long-term goal. I had also thought that in 
the medium-term, Velocity could be used because (as I understand it) it can 
also be used for scripted generation of static HTML sites (by running it in 
a 'batch' mode). However, I do agree with you about the short term goal 
being to improve the design and content of the existing site. "First we 
crawl....then we crawl on broken glass" (lovely quote from "Effective STL" ;-)

>Nonetheless, I think what we need on the site for now is some useful
>information about the project at hand, what its goals and who the people
>involved are, and all that preferably in some sort of half-way spiffy
>design. What might be a good starting point is the documentation already
>available (dev guide etc.) -- I guess reinventing the wheel is always a bad
>idea.

Yep. I think these are the pieces that we need (some of which we already 
have, although most will need updating for the next release):

Download, Build & Installation - should be fairly short, step-by-step 
guide, listing requirements and installation procedure as well as links to 
software on Sourceforge and CVS tree for the brave.

Developer's Guide - similar to the existing guide. I think the things to 
concentrate on are the "non-topic-map" parts of the toolkit. Things like 
the tm4j.net and tm4j.topicmap.utils packages (loading and saving) as well 
as TopicMapFactory, TopicMapProvider, and TopicMapProviderFactory.

Command-line App Documentation - we only have a couple of command-line apps 
in the distribution at the moment, but it would be good to develop a 
template for documenting such applications.

FAQ
         TM4J FAQ
         Topicmap FAQ (or a link to one)
         Topicmap Deesign FAQ (or a link to one)

Project Information -
         who does what
         To do list
         Plans for 0.6
         Links to related projects (e.g. other projects using TM4J or other 
topic-map related opensource projects)
         Links to TMAPI.

>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! :-)

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 ;-)


>So, perhaps it would be best if we concentrated on a standard-issue, static
>HTML site for now, and take a more relaxed approach for developing The TM4J
>Topic  Map (which we certainly need, but not just as a basis for a project
>web site). The brainstorm idea is great for that. How about if we set aside
>a directory in the CVS tree for that purpose? I guess it would make more
>sense to actually present one's views and ideas as Topic Maps, rather than
>having to use prose and e-mail.

That's a really good idea! I'll create a "sandbox" project in CVS that we 
can play in. Anyone who wants to post ideas who does not have CVS access 
should feel free to email them to me and I can upload them.

>And by the way, is this thread really where it's supposed to be? :-) I think
>that since we are discussing things pertaining primarily to development
>issues (OK, not Java code, but things that, for the most part, concern the
>project developers), wouldn't it be a better idea to move this over to
>tm4j-developers?

I debated that (with myself ;-) and thought that it might be nice to hear 
from any lurkers on this list as to what kinds of information you would 
like to see on the site. Otherwise we end up with "what the developers want 
to say" rather than "what the users want to know". So, lurkers, speak up!

Cheers,

Kal

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

[Florian H. <f.g...@gm...>]

[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.

Comments? Thoughts? Flames? :-)
-- Florian

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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

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

[Florian H. <f.g...@gm...>]

[Kal]
> 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.
> [...]

Let me just pitch in one quick thought, as I'm really tired tonight and
ought to get some sleep: what about Cocoon?

More tomorrow. |-)

-- Florian

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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

[Gerd M. <Ger...@sm...>]

On Wed, 21 Nov 2001 23:25:34 +0100 (MET)
Florian Haas <f.g...@gm...> wrote:

> [Kal]
> > 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.
> > [...]
> 
> Let me just pitch in one quick thought, as I'm really tired tonight and
> ought to get some sleep: what about Cocoon?

+1 from me. I've already built a simple TopicMap navigation tool
with TM4J on top of Cocoon. But to be honest, I don't know Velocity
very good, so I'm not sure about the pro's and con's. What I don't
like on JSP is the concept of writing Java Code in my HTML site.
Also, does it always need to be HTML when I use JSP ? Or is it also
possible to use XML ? I wouldn't like to be fixed on HTML. The
XML/XSLT approach it much flexible. E.g. we could print all the
stuff to PDF which is no problem with Cocoon.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

Re: [TM4J-users] TM4J project web site & XTM

[Niko S. <ni...@on...>]

On Thursday 22 November 2001 10:09, Gerd Mueller wrote:
> [...] What I don't like on JSP is the concept of writing Java Code in my 
> HTML site. [...]

Just to let you know, that this was on of our major design goals to have 
codefree HTML/XML pages when we designed the Navigator Framework 2nd 
Generation (which is used by Ontopia's Omnigator V). This is why we have 
chosen the Custom Tag Library aproach which allows also non programmers to 
participate in the Web App development. With this it's very easy (and just a 
few lines of XML statements) to retrieve information from your topicmap, 
process and present it (our custom tags are not allowed to produce any HTML)
meaning to embed it into whatever you like (HTML/XML/Plain) kind of velocity 
text generation tool, we have also written an environment for evaluating the 
pages outside a web container (for example from the command line).

> Also, does it always need to be HTML when I use JSP ? Or is it
> also possible to use XML ? I wouldn't like to be fixed on HTML. 

You are not bound a specific content type with JSP. So it is absolutely no 
problem to generate XML (for example we have built a WAP version of the 
Omnigator which renders WML).

Greetings,
Niko

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

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

At 10:09 22/11/2001 +0100, Gerd Mueller wrote:
>On Wed, 21 Nov 2001 23:25:34 +0100 (MET)
>Florian Haas <f.g...@gm...> wrote:
>
> > [Kal]
> > > 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.
> > > [...]
> >
> > Let me just pitch in one quick thought, as I'm really tired tonight and
> > ought to get some sleep: what about Cocoon?
>
>+1 from me. I've already built a simple TopicMap navigation tool
>with TM4J on top of Cocoon. But to be honest, I don't know Velocity
>very good, so I'm not sure about the pro's and con's. What I don't
>like on JSP is the concept of writing Java Code in my HTML site.
>Also, does it always need to be HTML when I use JSP ? Or is it also
>possible to use XML ? I wouldn't like to be fixed on HTML. The
>XML/XSLT approach it much flexible. E.g. we could print all the
>stuff to PDF which is no problem with Cocoon.

Cocoon would be interesting to look at. I followed it in its early releases 
but gave up when Cocoon 2 started to look Too Hard (tm ;-) Perhaps it is 
time to face that fear and revisit it. Cocoon's flexible styling would 
defn. be an advantage. However, if we are talking about large maps held in 
a backend such as Ozone, it would be impractical to run the XTM 
representation of the whole map through Cocoon each time we want to deliver 
a single page, so we need some method to serialize fragments of the topic 
map. JSP can provide that mechanism (it isn't limited to HTML) - in fact 
you can use the XSL document() function to invoke a JSP which generates the 
XML input to the XSLT processing...thats quite cool ;-)

Apart from the ability to swap stylesheets, what other advantages does 
Cocoon offer ? Can anyone summarize them for us ?

Cheers,

Kal

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

[Gerd M. <Ger...@sm...>]

> > > [Kal]
> > > > 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.
> > > > [...]
> > >
> > > Let me just pitch in one quick thought, as I'm really tired tonight and
> > > ought to get some sleep: what about Cocoon?
> >
> >+1 from me. I've already built a simple TopicMap navigation tool
> >with TM4J on top of Cocoon. But to be honest, I don't know Velocity
> >very good, so I'm not sure about the pro's and con's. What I don't
> >like on JSP is the concept of writing Java Code in my HTML site.
> >Also, does it always need to be HTML when I use JSP ? Or is it also
> >possible to use XML ? I wouldn't like to be fixed on HTML. The
> >XML/XSLT approach it much flexible. E.g. we could print all the
> >stuff to PDF which is no problem with Cocoon.
> 
> Cocoon would be interesting to look at. I followed it in its early releases 
> but gave up when Cocoon 2 started to look Too Hard (tm ;-) Perhaps it is 
> time to face that fear and revisit it. Cocoon's flexible styling would 
> defn. be an advantage. However, if we are talking about large maps held in 
> a backend such as Ozone, it would be impractical to run the XTM 
> representation of the whole map through Cocoon each time we want to deliver 
> a single page, so we need some method to serialize fragments of the topic 
> map. JSP can provide that mechanism (it isn't limited to HTML) - in fact 
> you can use the XSL document() function to invoke a JSP which generates the 
> XML input to the XSLT processing...thats quite cool ;-)
> 
> Apart from the ability to swap stylesheets, what other advantages does 
> Cocoon offer ? Can anyone summarize them for us ?

Cocoon2 offers a complete Web-Application runtime environment. You
can intergrate various datasources, such as SQL databases, handle
formular requests and it is extentable. Also I like the stream
based concept. The data is piped via SAX events through various
stages:

                      generator (database, etc.)
                         |
                        \|/
                  +-> transformer (XSL or something hardcoded)
                  |      |
                  +------+
                        \|/
                      serializer (HTML, PDF, etc.)

All this is defined in a sitemap. The only thing that isn't 
supported yet very well is some kind of page flow definition,
i.e. which page follows after a certain formular submit and
things like that. I like Cocoon, but I'm also open to learn 
something new like Velocity.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

[Jack P. <jac...@th...>]

At 10:09 AM 11/22/2001 +0100, Gerd Mueller wrote:
>I've already built a simple TopicMap navigation tool
>with TM4J on top of Cocoon.

I like Cocoon.  Gerd, can you say any more about the simple TM navigation 
tool you built for Cocoon?  I'd like to see it.

Cheers
Jack

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

[Gerd M. <Ger...@sm...>]

> At 10:09 AM 11/22/2001 +0100, Gerd Mueller wrote:
> >I've already built a simple TopicMap navigation tool
> >with TM4J on top of Cocoon.
> 
> I like Cocoon.  Gerd, can you say any more about the simple TM navigation 
> tool you built for Cocoon?  I'd like to see it.

Unfortunatly this is not possible right now since it doesn't work.
There some problems with the latest Cocoon version. But it is not
very sophisticated. The entry point is a list of all topics. If
you click on a topic you get an overview of it with all its names,
sub topics, parent topics, and the associations where it plays
a role. A similar page shows an overview of an association. So,
this tool presents the topicmap from a more technical point of view.

If I have the time I'll make it running again and provide an online
demo.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

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

[Florian H. <f.g...@gm...>]

Hello again!

[Kal]
> 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.

Which company was this?

[Kal]
> Apart from the ability to swap stylesheets, what other advantages does 
> Cocoon offer ? Can anyone summarize them for us ?

Not that this is anywhere near a decent *summary*, but there's a few things
I've noticed in Cocoon which don't seem to be implemented as nicely in
Velocity. Nonetheless I wouldn't say I were an expert at either, mind you.

* Better XSLFO support: wouldn't it be awesome to be able to browse, say,
the TM4J dev guide, in XHTML, on-line and at the same time have a PDF version
of same available at one click, all of which is generated from a single XTM
source tree?

* Nice built-in caching of XSLT output.

* No nitty-gritty special scripting language, just pure Java and XML for
Markup nerds like me. OK, I admit that last comment wasn't quite useful. :-)

Gerd, good to hear from you on the list! It's been way too quiet without
you. :-)

-- Florian





-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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

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

Its taken a little while to get round to answering this ...sorry about that!

At 12:32 23/11/2001 +0100, you wrote:
>Hello again!
>
>[Kal]
> > 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.
>
>Which company was this?

The company was Cogitech (www.cogx.com) - you can find some more examples 
and some interesting papers on creating and publishing both topic maps and 
RDF using XSLT.

>[Kal]
> > Apart from the ability to swap stylesheets, what other advantages does
> > Cocoon offer ? Can anyone summarize them for us ?
>
>Not that this is anywhere near a decent *summary*, but there's a few things
>I've noticed in Cocoon which don't seem to be implemented as nicely in
>Velocity. Nonetheless I wouldn't say I were an expert at either, mind you.
>
>* Better XSLFO support: wouldn't it be awesome to be able to browse, say,
>the TM4J dev guide, in XHTML, on-line and at the same time have a PDF version
>of same available at one click, all of which is generated from a single XTM
>source tree?
>
>* Nice built-in caching of XSLT output.
>
>* No nitty-gritty special scripting language, just pure Java and XML for
>Markup nerds like me. OK, I admit that last comment wasn't quite useful. :-)

The caching and the use of compiled XSLT "translets" looks quite good. I 
notice that Cocoon 2.0 is now an official release. From what I have read, I 
think it should be possible to develop a "Generator" for Cocoon that 
extracts topic map data (as XTM format XML ?) and passes it on to what ever 
transformer or serializer modules you care to include. This would work 
really nicely for a "dynamic" site - where you are able to run a servlet 
container on the host machine. However, for our Sourceforge site, and for 
countless other "simple" sites, running servlets is not an option - there 
may be some PHP or Perl support and maybe an mSQL database (if you are 
lucky) but for the most part, you are limted to static HTML. For those 
sites, a Velocity based, scripted static transformation might be a better 
way to go.

If there are volunteers to take on the Cocoon 2.0 generator, I think that 
would be a really worthwhile application. Also if anyone cares to volunteer 
for developing a framework for static transformation (using XSLT or 
Velocity or a combination of the two), that would also be really worthwhile.

I think this discussion is rapidly becoming more of a technical / TM4J 
development issue than an issue of website content. I am therefore copying 
the message to tm4j-developers and would ask that all replies get sent to 
that list.

Cheers,

Kal