Menu
▾
▴
tm4j-developers
|
From: Kal A. <ka...@te...> - 2003-01-23 10:54:21
|
Apologies for the cross-posting, I just wanted to be sure that I got=20 everyone's attention ;-) A while ago, Florian Haas and Thomas Bauer contributed a package called T= M4Web=20 to the TM4J Project. This package contains a set of stylesheets for=20 converting XTM syntax topic maps into a collection of HTML pages using th= e=20 page-per-topic style of the TM4J.org website. Separately from that work, I had developed a template-based mechanism for= =20 creating HTML pages directly from a TM4J TopicMap which works both as a=20 servlet and as a stand-alone application. Separately from that, I have played with Cocoon and the TM4Web stylesheet= s to=20 create a little sample webapp that uses TM4J APIs to extract topic map=20 fragments and TM4Web stylesheets to create the HTML output in a Cocoon=20 processing pipe. Separately from *that*, Christoph Frolich, Niko Schmuck and Martin Stockh= ammer=20 are working on TMNav which, while aimed more at the development of GUI to= ols,=20 has a strong web application component with a WS interface and with a=20 flexible abstraction and rendering process which would work well in a web= =20 application. Separately from all of that, I know that a number of people are using TM4= J to=20 create web applications using a wide variety of frameworks and toolkits. What we all have in common is that we are creating web applications for=20 presenting and/or modifying topic maps in a browser, but we are taking=20 different approaches with different focusses and different strenghts and=20 weaknesses. My feeling is that this is all good. What I would like to do is to use TM4Web as a banner project for bringing= =20 together design approaches; patterns for rendering topic maps; utility=20 classes and sample tools and applications all with the aim of making it e= asy=20 for developers to find some starting point for their own applications. T= his=20 is quite a big undertaking and I would like to get an idea about how much= =20 support there is for this in the community. Do you think that this approach is a good idea, or would you prefer to se= e the=20 TM4J project produce a single one-size-fits-all solution for topic maps o= n=20 the web ? Do you have any experience and/or sample code which you might consider=20 contributing to TM4Web ? Am I just mad for even contemplating this ? (probably) Any thoughts / opinions gratefully received. Cheers, Kal =20 --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Jack P. <jac...@th...> - 2003-01-23 16:04:15
|
Kal, you are not even close to "mad" contemplating this. Here is why, in my view: Recently, a bunch of friends and I were treated to a demonstration of Zope with Plone. I confess, it was awesome, something any Web developer would drool over. I understand there's even a topic map engine for Zope in the works. I was asked how come there isn't something equivalent in Javaland. Well, there is, almost, and it is Cocoon, or maybe JBoss, or maybe JBoss/Cocoon. But, they are not even close. Here is why I think that is so. The demonstration was given by a fellow who ostensibly is not a programmer. He is a Web developer, probably skilled in HTML and so forth. The issue is this: the work is already done. Install Zope, drop Plone into it, and you pretty much have nearly everything you need. No need to get involved with XML of any kind. Just go to the control panel and set things up the way you want them. I would be more than happy to stand corrected, but for now, in my view, there's nothing like that (in terms of completeness) running in Java. If Zope gets a potent topic map engine, then the floodgate of topic map applications that I think lies waiting to open will do so. From the standpoint of content management, there are a bunch of really slick apps out there (dspace, wynona, etc) all of which are more than ready for topic map implementation, none of which is as "light switch simple" as the Zope/Plone ensemble. Therefore, I am very much interested in the kinds of things you are speaking about here. Particularly, I look at it this way. JBoss advertises scalability. Cocoon advertises completeness. Put the two together, strip out the unnecessary J2EE stuff, and you're quite close to a good starting point. But, where are the applications? There was an article on building portals with Cocoon. That's a pretty good start. There's supposed to be a Wiki for Cocoon. I haven't seen it working. There's supposed to be a blog engine for Cocoon. I haven't seen it working. My view is, therefore, that we must strive to complete the ensemble of Web applications available in Java, and do so with topic maps as the underlying, centralizing glue that binds. TM4J strikes me as a powerful way to make that happen. What the world (according to Park) is waiting for is a light-switch easy Webportal engine built around topic maps. No user of that engine should ever have to touch HTML, XML, XTM, or any such technology unless they want to. Zope/Plone is very close (but, no cigar quite yet) to that level of development. The world (still according to Park) probably needs some of the collective sensemaking ideas I have outlined elsewhere (e.g. http://www.nexist.org/sc2002/). These should, I think, be built-in functionality that resides as part of the topic map facility. The projects you enumerate below are, to me, clear evidence that we are already aimed in the right direction. What's missing? I think what's missing is an attempt to integrate those and other emerging projects into a light switch easy package. That's my 0.125 EUROs for the day. Cheers Jack At 11:11 AM 1/23/2003 +0000, Kal Ahmed wrote: >Apologies for the cross-posting, I just wanted to be sure that I got >everyone's attention ;-) > >A while ago, Florian Haas and Thomas Bauer contributed a package called >TM4Web >to the TM4J Project. This package contains a set of stylesheets for >converting XTM syntax topic maps into a collection of HTML pages using the >page-per-topic style of the TM4J.org website. > >Separately from that work, I had developed a template-based mechanism for >creating HTML pages directly from a TM4J TopicMap which works both as a >servlet and as a stand-alone application. > >Separately from that, I have played with Cocoon and the TM4Web stylesheets to >create a little sample webapp that uses TM4J APIs to extract topic map >fragments and TM4Web stylesheets to create the HTML output in a Cocoon >processing pipe. > >Separately from *that*, Christoph Frolich, Niko Schmuck and Martin >Stockhammer >are working on TMNav which, while aimed more at the development of GUI tools, >has a strong web application component with a WS interface and with a >flexible abstraction and rendering process which would work well in a web >application. > >Separately from all of that, I know that a number of people are using TM4J to >create web applications using a wide variety of frameworks and toolkits. > >What we all have in common is that we are creating web applications for >presenting and/or modifying topic maps in a browser, but we are taking >different approaches with different focusses and different strenghts and >weaknesses. > >My feeling is that this is all good. > >What I would like to do is to use TM4Web as a banner project for bringing >together design approaches; patterns for rendering topic maps; utility >classes and sample tools and applications all with the aim of making it easy >for developers to find some starting point for their own applications. This >is quite a big undertaking and I would like to get an idea about how much >support there is for this in the community. > >Do you think that this approach is a good idea, or would you prefer to see >the >TM4J project produce a single one-size-fits-all solution for topic maps on >the web ? > >Do you have any experience and/or sample code which you might consider >contributing to TM4Web ? > >Am I just mad for even contemplating this ? (probably) > >Any thoughts / opinions gratefully received. > >Cheers, > >Kal > >-- >Kal Ahmed, techquila.com >XML and Topic Map Consultancy > >e: ka...@te... >p: +44 7968 529531 >w: www.techquila.com > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally and you reduce the need for smarter bombs. |
|
From: Kal A. <ka...@te...> - 2003-01-25 14:03:06
|
Jack, Thanks for your reply. While I do agree with you that a simple content=20 management system is still something that is missing from the open-source= =20 world, and also that topic maps have a role to play in such a system, I a= m=20 not sure whether I could commit to starting on such a project myself. Th= e=20 TM4J core code takes a fair amount of my time in terms of development and= =20 support. A new CMS really requires a technical architect/lead developer w= ho=20 can commit as much of their free time to it as possible to get off the gr= ound=20 - just the sheer amount of work that would be needed to make a 0.1 let al= one=20 a 1.0 release of such a system is something that I cannot really contempl= ate=20 right now. However, what I do think would be a valuable contribution and a step in t= he=20 right direction would be to gather together the combined experience of fo= lks=20 on this list (and others) who have started down the road of using topic m= aps=20 as the organising principle for web content. I do agree with you that there is alot of the groundwork for a useful CMS= =20 application using TM4J to be built, I'm just not sure whether that should= be=20 the focus of TM4Web, or if it would not be better to create the hooks int= o=20 existing web application frameworks that might allow others to develop su= ch a=20 system. However, I'm not closed to the possibility of working on such a system, n= or am=20 I closed to the possibility of TM4Web turning into such a system, I'm jus= t=20 sceptical that that would happen without another developer joining with t= hat=20 as his or her primary focus. Cheers, Kal PS - the Zope topic map system is a project on sourceforge=20 http://sourceforge.net/projects/ztm - I haven't played with it yet though= I=20 will...perhaps doing so will change my mind!=20 On Thursday 23 January 2003 16:02, Jack Park wrote: > Kal, you are not even close to "mad" contemplating this. Here is why, = in > my view: > > Recently, a bunch of friends and I were treated to a demonstration of Z= ope > with Plone. I confess, it was awesome, something any Web developer wou= ld > drool over. I understand there's even a topic map engine for Zope in th= e > works. > > I was asked how come there isn't something equivalent in Javaland. Wel= l, > there is, almost, and it is Cocoon, or maybe JBoss, or maybe JBoss/Coco= on. > But, they are not even close. Here is why I think that is so. > > The demonstration was given by a fellow who ostensibly is not a program= mer. > He is a Web developer, probably skilled in HTML and so forth. The issue= is > this: the work is already done. Install Zope, drop Plone into it, and y= ou > pretty much have nearly everything you need. No need to get involved wi= th > XML of any kind. Just go to the control panel and set things up the way= you > want them. > > I would be more than happy to stand corrected, but for now, in my view, > there's nothing like that (in terms of completeness) running in Java. = If > Zope gets a potent topic map engine, then the floodgate of topic map > applications that I think lies waiting to open will do so. > > From the standpoint of content management, there are a bunch of really > slick apps out there (dspace, wynona, etc) all of which are more than r= eady > for topic map implementation, none of which is as "light switch simple"= as > the Zope/Plone ensemble. > > Therefore, I am very much interested in the kinds of things you are > speaking about here. Particularly, I look at it this way. > > JBoss advertises scalability. Cocoon advertises completeness. Put the t= wo > together, strip out the unnecessary J2EE stuff, and you're quite close = to a > good starting point. But, where are the applications? There was an art= icle > on building portals with Cocoon. That's a pretty good start. There's > supposed to be a Wiki for Cocoon. I haven't seen it working. There's > supposed to be a blog engine for Cocoon. I haven't seen it working. > > My view is, therefore, that we must strive to complete the ensemble of = Web > applications available in Java, and do so with topic maps as the > underlying, centralizing glue that binds. TM4J strikes me as a powerful= way > to make that happen. What the world (according to Park) is waiting for= is > a light-switch easy Webportal engine built around topic maps. No user o= f > that engine should ever have to touch HTML, XML, XTM, or any such > technology unless they want to. Zope/Plone is very close (but, no cigar > quite yet) to that level of development. > > The world (still according to Park) probably needs some of the collecti= ve > sensemaking ideas I have outlined elsewhere (e.g. > http://www.nexist.org/sc2002/). These should, I think, be built-in > functionality that resides as part of the topic map facility. > > The projects you enumerate below are, to me, clear evidence that we are > already aimed in the right direction. What's missing? I think what's > missing is an attempt to integrate those and other emerging projects in= to a > light switch easy package. > > That's my 0.125 EUROs for the day. > Cheers > Jack > > At 11:11 AM 1/23/2003 +0000, Kal Ahmed wrote: > >Apologies for the cross-posting, I just wanted to be sure that I got > >everyone's attention ;-) > > > >A while ago, Florian Haas and Thomas Bauer contributed a package calle= d > >TM4Web > >to the TM4J Project. This package contains a set of stylesheets for > >converting XTM syntax topic maps into a collection of HTML pages using= the > >page-per-topic style of the TM4J.org website. > > > >Separately from that work, I had developed a template-based mechanism = for > >creating HTML pages directly from a TM4J TopicMap which works both as = a > >servlet and as a stand-alone application. > > > >Separately from that, I have played with Cocoon and the TM4Web stylesh= eets > > to create a little sample webapp that uses TM4J APIs to extract topic= map > > fragments and TM4Web stylesheets to create the HTML output in a Cocoo= n > > processing pipe. > > > >Separately from *that*, Christoph Frolich, Niko Schmuck and Martin > >Stockhammer > >are working on TMNav which, while aimed more at the development of GUI > > tools, has a strong web application component with a WS interface and > > with a flexible abstraction and rendering process which would work we= ll > > in a web application. > > > >Separately from all of that, I know that a number of people are using = TM4J > > to create web applications using a wide variety of frameworks and > > toolkits. > > > >What we all have in common is that we are creating web applications fo= r > >presenting and/or modifying topic maps in a browser, but we are taking > >different approaches with different focusses and different strenghts a= nd > >weaknesses. > > > >My feeling is that this is all good. > > > >What I would like to do is to use TM4Web as a banner project for bring= ing > >together design approaches; patterns for rendering topic maps; utility > >classes and sample tools and applications all with the aim of making i= t > > easy for developers to find some starting point for their own > > applications. This is quite a big undertaking and I would like to ge= t an > > idea about how much support there is for this in the community. > > > >Do you think that this approach is a good idea, or would you prefer to= see > >the > >TM4J project produce a single one-size-fits-all solution for topic map= s on > >the web ? > > > >Do you have any experience and/or sample code which you might consider > >contributing to TM4Web ? > > > >Am I just mad for even contemplating this ? (probably) > > > >Any thoughts / opinions gratefully received. > > > >Cheers, > > > >Kal > > > >-- > >Kal Ahmed, techquila.com > >XML and Topic Map Consultancy > > > >e: ka...@te... > >p: +44 7968 529531 > >w: www.techquila.com > > > > > > > >------------------------------------------------------- > >This SF.NET email is sponsored by: > >SourceForge Enterprise Edition + IBM + LinuxWorld > > http://www.vasoftware.com ___________________________________________= ____ > >Tm4j-developers mailing list > >Tm4...@li... > >https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > -----------------------------------------------------------------------= ---- > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally and you reduce the need for smarter bombs. --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Jack P. <jac...@th...> - 2003-01-25 15:03:57
|
Kal, I'm not sure that I was actually calling for a massive effort on your part, or, necessarily, on any individual's part to mount the giant horse that would take us into the CMS battlefield. Indeed, what with topic maps, maybe the game isn't content management at all; rather it might be subject management. Rather, I think I was mostly pointing out that, in terms of mind share of users 'out there', we Java jockeys have a long way to go before we appear (appearances are nearly everything, these days) competitive. There are some truly awesome Java-based CMS tools out there, none of which touches topic maps at all. Overall, I return to my original point that there is really little if anything available in Java that one could call a complete Webportal system. I think my point was that your call for the future of TM4Web might be a useful starting point where the target is to enable other projects (e.g. DSpace, Cocoon, etc) to become, um, finished. Cheers Jack At 02:21 PM 1/25/2003 +0000, Kal Ahmed wrote: >Jack, > >Thanks for your reply. While I do agree with you that a simple content >management system is still something that is missing from the open-source >world, and also that topic maps have a role to play in such a system, I am >not sure whether I could commit to starting on such a project myself. The >TM4J core code takes a fair amount of my time in terms of development and >support. A new CMS really requires a technical architect/lead developer who >can commit as much of their free time to it as possible to get off the ground >- just the sheer amount of work that would be needed to make a 0.1 let alone >a 1.0 release of such a system is something that I cannot really contemplate >right now. > >However, what I do think would be a valuable contribution and a step in the >right direction would be to gather together the combined experience of folks >on this list (and others) who have started down the road of using topic maps >as the organising principle for web content. > >I do agree with you that there is alot of the groundwork for a useful CMS >application using TM4J to be built, I'm just not sure whether that should be >the focus of TM4Web, or if it would not be better to create the hooks into >existing web application frameworks that might allow others to develop such a >system. > >However, I'm not closed to the possibility of working on such a system, >nor am >I closed to the possibility of TM4Web turning into such a system, I'm just >sceptical that that would happen without another developer joining with that >as his or her primary focus. > >Cheers, > >Kal > >PS - the Zope topic map system is a project on sourceforge >http://sourceforge.net/projects/ztm - I haven't played with it yet though I >will...perhaps doing so will change my mind! > > >On Thursday 23 January 2003 16:02, Jack Park wrote: > > Kal, you are not even close to "mad" contemplating this. Here is why, in > > my view: > > > > Recently, a bunch of friends and I were treated to a demonstration of Zope > > with Plone. I confess, it was awesome, something any Web developer would > > drool over. I understand there's even a topic map engine for Zope in the > > works. > > > > I was asked how come there isn't something equivalent in Javaland. Well, > > there is, almost, and it is Cocoon, or maybe JBoss, or maybe JBoss/Cocoon. > > But, they are not even close. Here is why I think that is so. > > > > The demonstration was given by a fellow who ostensibly is not a programmer. > > He is a Web developer, probably skilled in HTML and so forth. The issue is > > this: the work is already done. Install Zope, drop Plone into it, and you > > pretty much have nearly everything you need. No need to get involved with > > XML of any kind. Just go to the control panel and set things up the way you > > want them. > > > > I would be more than happy to stand corrected, but for now, in my view, > > there's nothing like that (in terms of completeness) running in Java. If > > Zope gets a potent topic map engine, then the floodgate of topic map > > applications that I think lies waiting to open will do so. > > > > From the standpoint of content management, there are a bunch of really > > slick apps out there (dspace, wynona, etc) all of which are more than ready > > for topic map implementation, none of which is as "light switch simple" as > > the Zope/Plone ensemble. > > > > Therefore, I am very much interested in the kinds of things you are > > speaking about here. Particularly, I look at it this way. > > > > JBoss advertises scalability. Cocoon advertises completeness. Put the two > > together, strip out the unnecessary J2EE stuff, and you're quite close to a > > good starting point. But, where are the applications? There was an article > > on building portals with Cocoon. That's a pretty good start. There's > > supposed to be a Wiki for Cocoon. I haven't seen it working. There's > > supposed to be a blog engine for Cocoon. I haven't seen it working. > > > > My view is, therefore, that we must strive to complete the ensemble of Web > > applications available in Java, and do so with topic maps as the > > underlying, centralizing glue that binds. TM4J strikes me as a powerful way > > to make that happen. What the world (according to Park) is waiting for is > > a light-switch easy Webportal engine built around topic maps. No user of > > that engine should ever have to touch HTML, XML, XTM, or any such > > technology unless they want to. Zope/Plone is very close (but, no cigar > > quite yet) to that level of development. > > > > The world (still according to Park) probably needs some of the collective > > sensemaking ideas I have outlined elsewhere (e.g. > > http://www.nexist.org/sc2002/). These should, I think, be built-in > > functionality that resides as part of the topic map facility. > > > > The projects you enumerate below are, to me, clear evidence that we are > > already aimed in the right direction. What's missing? I think what's > > missing is an attempt to integrate those and other emerging projects into a > > light switch easy package. > > > > That's my 0.125 EUROs for the day. > > Cheers > > Jack > > > > At 11:11 AM 1/23/2003 +0000, Kal Ahmed wrote: > > >Apologies for the cross-posting, I just wanted to be sure that I got > > >everyone's attention ;-) > > > > > >A while ago, Florian Haas and Thomas Bauer contributed a package called > > >TM4Web > > >to the TM4J Project. This package contains a set of stylesheets for > > >converting XTM syntax topic maps into a collection of HTML pages using the > > >page-per-topic style of the TM4J.org website. > > > > > >Separately from that work, I had developed a template-based mechanism for > > >creating HTML pages directly from a TM4J TopicMap which works both as a > > >servlet and as a stand-alone application. > > > > > >Separately from that, I have played with Cocoon and the TM4Web stylesheets > > > to create a little sample webapp that uses TM4J APIs to extract topic map > > > fragments and TM4Web stylesheets to create the HTML output in a Cocoon > > > processing pipe. > > > > > >Separately from *that*, Christoph Frolich, Niko Schmuck and Martin > > >Stockhammer > > >are working on TMNav which, while aimed more at the development of GUI > > > tools, has a strong web application component with a WS interface and > > > with a flexible abstraction and rendering process which would work well > > > in a web application. > > > > > >Separately from all of that, I know that a number of people are using TM4J > > > to create web applications using a wide variety of frameworks and > > > toolkits. > > > > > >What we all have in common is that we are creating web applications for > > >presenting and/or modifying topic maps in a browser, but we are taking > > >different approaches with different focusses and different strenghts and > > >weaknesses. > > > > > >My feeling is that this is all good. > > > > > >What I would like to do is to use TM4Web as a banner project for bringing > > >together design approaches; patterns for rendering topic maps; utility > > >classes and sample tools and applications all with the aim of making it > > > easy for developers to find some starting point for their own > > > applications. This is quite a big undertaking and I would like to get an > > > idea about how much support there is for this in the community. > > > > > >Do you think that this approach is a good idea, or would you prefer to see > > >the > > >TM4J project produce a single one-size-fits-all solution for topic maps on > > >the web ? > > > > > >Do you have any experience and/or sample code which you might consider > > >contributing to TM4Web ? > > > > > >Am I just mad for even contemplating this ? (probably) > > > > > >Any thoughts / opinions gratefully received. > > > > > >Cheers, > > > > > >Kal > > > > > >-- > > >Kal Ahmed, techquila.com > > >XML and Topic Map Consultancy > > > > > >e: ka...@te... > > >p: +44 7968 529531 > > >w: www.techquila.com > > > > > > > > > > > >------------------------------------------------------- > > >This SF.NET email is sponsored by: > > >SourceForge Enterprise Edition + IBM + LinuxWorld > > > http://www.vasoftware.com _______________________________________________ > > >Tm4j-developers mailing list > > >Tm4...@li... > > >https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > > > --------------------------------------------------------------------------- > > XML Topic Maps: Creating and Using Topic Maps for the Web. > > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > > > Build smarter kids globally and you reduce the need for smarter bombs. > >-- >Kal Ahmed, techquila.com >XML and Topic Map Consultancy > >e: ka...@te... >p: +44 7968 529531 >w: www.techquila.com --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally and you reduce the need for smarter bombs. |
|
From: Florian G. H. <fg...@bk...> - 2003-01-26 22:54:46
|
Hello everyone. On Thursday 23 January 2003 17:02, Jack Park wrote: | My view is, therefore, that we must strive to complete the ensemble of = Web | applications available in Java, and do so with topic maps as the | underlying, centralizing glue that binds. TM4J strikes me as a powerful= way | to make that happen. What the world (according to Park) is waiting for= is | a light-switch easy Webportal engine built around topic maps. No user o= f | that engine should ever have to touch HTML, XML, XTM, or any such | technology unless they want to. Zope/Plone is very close (but, no cigar | quite yet) to that level of development. Permit me to add something along these lines. Cocoon, for example, is gre= at=20 but it's of course far from being "light switch easy" as Jack puts it.=20 Downloading and installing Cocoon, and getting it running, is a snap, and= =20 looking at the samples and config files you just get this "wow, this is=20 really neat" kind of feeling. But if you're trying to go beyond the sampl= e=20 applications and the trivial "Hello World" stuff, well, it's a different=20 story. As for my part, I've been trying to set up a simple processing=20 environment for all the documentation I write using DocBook, with a tiny = web=20 GUI for the purpose of customizing Norm Walsh's docbook-xsl stylesheet=20 collection (setting parameters, overriding templates etc.). And much to m= y=20 despair, I failed miserably and decided I'd better go back to tweak my AN= T=20 build environment, which is the approach I've followed ever since. Now, as much as I'd like a ready-made DocBook XML processing environment = =20 pluggable into Cocoon, an XTM processing environment should be just as=20 wonderful to have. I think TM4J has already taken the right steps in the=20 right direction with the approach of defining a set of interfaces to inte= ract=20 with any number of back-ends. What TM4web should now do, in my very humbl= e=20 opinion, is provide the connection to the other end, the whole=20 user-interaction layer. Providing XSL stylesheets for XSLT transformation= =20 environments is one approach, Velocity templates for servlet-based=20 applications another, and GUI tools a third (insert as many others as you= r=20 imagination allows). If we were to define a set of guidelines describing a TM4J frontend just = as=20 the engine prescribes the guidelines for the various backends, I think th= at=20 might get us where we want to go. It is, of course, a whole lot more=20 difficult to do this on the user end -- as for the backends, a formal=20 definition structure is provided by the use of Java interfaces. It's=20 comparatively easy to say, this backend is TM4J 'compatible' or not -- if= it=20 implements the interfaces, it is, if it doesn't it's not. On the front en= d,=20 it's a different story. When is a set of Cocoon generators, pipelines, an= d=20 transformers (or a bunch of Velocity templates, etc. etc.) "a TM4J fronte= nd"?=20 I believe if we had such guidelines, that could be the glue that holds a=20 "frontend framework" (call it TM4web or else) together.=20 I'm afraid that this might sound all a little like PHB-ish, commercial=20 software development style, "project charter" gibberish. I also understan= d=20 that this calls for providing and maintaining high-quality (albeit perhap= s=20 not even very extensive, I stress that's "quality", not "quantity"). And = I=20 understand that my reasoning here is certainly influenced by my own=20 non-strict-coder background. All in all, I realize that perhaps you'll ha= te=20 it. :-) Worse still, I don't know any formal approach to defining such a set of=20 guidelines. Anybody have experience with regard to this? Would one have t= o=20 define it in prose (such as an authoritative "TM4J frontend designer's=20 guide"), or is there something more efficient that perhaps even code=20 generators could work with? =20 My humble own bottom line is this: if we get the TM4J frontends to march = in=20 step the way the backends do (well, except the DOM backend, for lack of t= ime=20 on my part, mea culpa :-( ), this would really be something that could gi= ve=20 potential users a chance to just *try TM4J out* without having to write c= ode=20 themselves or resort to JUnit test cases. In other words, we would move f= rom=20 appealing to developers to appealing to users. Plus, we would contribute=20 enormously to projects like Cocoon or Axis or perhaps Xindice who seem to= be=20 suffering from similar symptoms of users asking "OK, I see this is great,= but=20 What's In It For Me?" Or am I perhaps missing the point here completely? :-) -- Florian |
|
From: Martin S. <m.s...@we...> - 2003-02-02 22:11:39
|
Hi, a bit late, but I want to tell you some of my thoughts about this. I think because of the restricted ressources we have (developers, time, ...) we should concentrate on goals we are able to achieve. Maybe there is a lack of Easy-To-Use-Webportal-Engine's in the java open source world, but there are many efforts to develop such applications (see cocoon, jetspeed, ...) and as you can see it costs a lot of work and time to do this. And I think at the time it's not really a problem, that there are no easy webportal engines available, because most of the people who use java open source web applications, are developers and need flexible and easy adaptable frameworks for their projects. Back to tm4j and tm4web: tm4j is a very powerful backend, but what we need now are frontends to tm4j. tm4web is a special solution for web frontends and at the time (as I know, but I know it not very well) it consists of a bunch of stylesheets to transform the XML-Representation of a topic map to HTML. tmnav is a more general approach to the frontend problem. The goal of the panckoucke library of tmnav is to provide a general framework to navigate and edit topic maps, undependent of the type of frontend. And there are some subprojects, frontends that use panckoucke, (e.g a swing frontend, a webservice). But this means at the time it is NOT easy to use. It is more work, because you have to provide clean interfaces and you have to develop the library AND frontend applications. Therefore it will not be easy to use in the near time. But it will allow to write adapters for other web-application/web-portal-engines e.g. to cocoon. So we do not have to reinvent the wheel again, but we can use the existing applications out there as frontends. So I think with tmnav/panckoucke we have the "frontend framework" that you mentioned, but at the time it is not in a state that allows to adapt a web-frontend easily. So what can we do? One way is to develop both, the web-frontends and other frontends on base of the panckoucke-Library. But this means a lot of communication between the developers to find out what is needed and to develop the interfaces. And it takes more time to develop easy-to-use applications. Another way is to develop both, tmnav with panckoucke as general approach, and tm4web as special web-frontend framework for tm4j. And maybe try to put them together in the far future. But this means to do some work double. I do not know what's the best solution. But I think we should try to find out, what are the special demands of web applications that use tm4j and if panckoucke is/will be able to fullful this demands or if we need another approach. I'm very new to the tmnav-Team, so it is possible that it is not all correct that I said about the goals/abilities of panckoucke. I hope Niko or Christoph will correct it or write their own opinion about it. Bye Martin Florian G. Haas wrote: > Hello everyone. > > On Thursday 23 January 2003 17:02, Jack Park wrote: > | My view is, therefore, that we must strive to complete the ensemble of Web > | applications available in Java, and do so with topic maps as the > | underlying, centralizing glue that binds. TM4J strikes me as a powerful way > | to make that happen. What the world (according to Park) is waiting for is > | a light-switch easy Webportal engine built around topic maps. No user of > | that engine should ever have to touch HTML, XML, XTM, or any such > | technology unless they want to. Zope/Plone is very close (but, no cigar > | quite yet) to that level of development. > > Permit me to add something along these lines. Cocoon, for example, is great > but it's of course far from being "light switch easy" as Jack puts it. > Downloading and installing Cocoon, and getting it running, is a snap, and > looking at the samples and config files you just get this "wow, this is > really neat" kind of feeling. But if you're trying to go beyond the sample > applications and the trivial "Hello World" stuff, well, it's a different > story. As for my part, I've been trying to set up a simple processing > environment for all the documentation I write using DocBook, with a tiny web > GUI for the purpose of customizing Norm Walsh's docbook-xsl stylesheet > collection (setting parameters, overriding templates etc.). And much to my > despair, I failed miserably and decided I'd better go back to tweak my ANT > build environment, which is the approach I've followed ever since. > > Now, as much as I'd like a ready-made DocBook XML processing environment > pluggable into Cocoon, an XTM processing environment should be just as > wonderful to have. I think TM4J has already taken the right steps in the > right direction with the approach of defining a set of interfaces to interact > with any number of back-ends. What TM4web should now do, in my very humble > opinion, is provide the connection to the other end, the whole > user-interaction layer. Providing XSL stylesheets for XSLT transformation > environments is one approach, Velocity templates for servlet-based > applications another, and GUI tools a third (insert as many others as your > imagination allows). > > If we were to define a set of guidelines describing a TM4J frontend just as > the engine prescribes the guidelines for the various backends, I think that > might get us where we want to go. It is, of course, a whole lot more > difficult to do this on the user end -- as for the backends, a formal > definition structure is provided by the use of Java interfaces. It's > comparatively easy to say, this backend is TM4J 'compatible' or not -- if it > implements the interfaces, it is, if it doesn't it's not. On the front end, > it's a different story. When is a set of Cocoon generators, pipelines, and > transformers (or a bunch of Velocity templates, etc. etc.) "a TM4J frontend"? > > I believe if we had such guidelines, that could be the glue that holds a > "frontend framework" (call it TM4web or else) together. > > I'm afraid that this might sound all a little like PHB-ish, commercial > software development style, "project charter" gibberish. I also understand > that this calls for providing and maintaining high-quality (albeit perhaps > not even very extensive, I stress that's "quality", not "quantity"). And I > understand that my reasoning here is certainly influenced by my own > non-strict-coder background. All in all, I realize that perhaps you'll hate > it. :-) > > Worse still, I don't know any formal approach to defining such a set of > guidelines. Anybody have experience with regard to this? Would one have to > define it in prose (such as an authoritative "TM4J frontend designer's > guide"), or is there something more efficient that perhaps even code > generators could work with? > > My humble own bottom line is this: if we get the TM4J frontends to march in > step the way the backends do (well, except the DOM backend, for lack of time > on my part, mea culpa :-( ), this would really be something that could give > potential users a chance to just *try TM4J out* without having to write code > themselves or resort to JUnit test cases. In other words, we would move from > appealing to developers to appealing to users. Plus, we would contribute > enormously to projects like Cocoon or Axis or perhaps Xindice who seem to be > suffering from similar symptoms of users asking "OK, I see this is great, but > What's In It For Me?" > > Or am I perhaps missing the point here completely? :-) > -- Florian > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! > http://www.vasoftware.com > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: Kal A. <ka...@te...> - 2003-02-03 19:35:52
|
Hi, Firstly, thanks to everyone who replied both on and off the list. It seems that the general consensus is that tm4web should *not* aim to be a one-size-fits-all topic map browsing/editing solution and that it should be more than the current set of (albeit very useful) stylesheets. Nailing down exactly what the in-between is that tm4web should be is going to be harder. I agree with Martin's analysis of the panckouke library - it is essentially a way to bind the topic map data model to something which is perhaps easier to process for front-ends (both web and desktop). In thinking about what everyone has written, I keep coming back to the same thoughts - that it would be really nice to have features in the TM4J library that help people trying to build web applications. There are already some classes whose motivation was web applications, such as the TopicMapManager and the TopicMapFragment classes. The whole concept of extractors and testers is also really there to help application developers (though not just for web applications). So, what could the tm4web sub-project aim to produce ? Here are my thoughts: 0) Static transformation using XSL stylesheets 1) Some utility classes for configuring the connection to one or more TM4J back-ends 2) Utility classes to support the direct interfacing of TM4J to Velocity 3) Utility classes to support the direct interfacing of TM4J to Cocoon (implemented as Cocoon transformers for example) 4) Utility classes for integrating tmnav libraries with the backend configurations from (1) and for interfacing the panckouke abstraction model to Velocity/Cocoon 5) JBoss integration ? 6) Some cool demo apps 7) How-tos, sample code and tips from people who have already done this kind of stuff with TM4J. I think that (4) will be the framework that provides the ultimate level of flexibility, but (2) and (3) will be simpler frameworks which might allow developers to "get the job done" - I am especially thinking of cases where Velocity/Cocoon is used to do a static transformation of an entire topic map into HTML pages (rather than serving HTML on the fly). (6) will be the way to showcase all of these different ways of doing things - the Velocity/Struts project has a nice set of demos where you can compare the Struts w/ JSP method with the Struts w/ Velocity method - perhaps something similar would be good for tm4web For (0), I think that the existing system could be nicely enhanced with a simple command-line application that combines the processing of one or more topic maps into a single consistent topic map with the actual XSL transformation - the app could also be used to allow the transformation of topic maps from the persistent backends with the stylesheet. Part of this work would be to create an XMLReader implementation for a TopicMap object so that a TopicMap object could be read as a Source for a TRAX transformation. Thoughts ? Is there something else that I have missed from this list ? Cheers, Kal On Sun, 2003-02-02 at 22:16, Martin Stockhammer wrote: > Hi, > > a bit late, but I want to tell you some of my thoughts about this. > I think because of the restricted ressources we have (developers, time, ...) > we should concentrate on goals we are able to achieve. > Maybe there is a lack of Easy-To-Use-Webportal-Engine's in the java > open source world, but there are many efforts to develop such applications > (see cocoon, jetspeed, ...) and as you can see it costs a lot of work and > time to do this. > And I think at the time it's not really a problem, that there are no easy webportal engines > available, because most of the people who use java open source > web applications, are developers and need flexible and easy adaptable > frameworks for their projects. > > Back to tm4j and tm4web: tm4j is a very powerful backend, > but what we need now are frontends to tm4j. > tm4web is a special solution for web frontends and at the time (as I know, but > I know it not very well) it consists of a bunch of stylesheets to transform the > XML-Representation of a topic map to HTML. > > tmnav is a more general approach to the frontend problem. The goal of the panckoucke library > of tmnav is to provide a general framework to navigate and edit topic maps, undependent > of the type of frontend. And there are some subprojects, frontends that use panckoucke, > (e.g a swing frontend, a webservice). But this means at the time it is NOT easy to use. > It is more work, because you have to provide clean interfaces and you have to develop the > library AND frontend applications. Therefore it will not be easy to use in the near time. > But it will allow to write adapters for other web-application/web-portal-engines e.g. to > cocoon. So we do not have to reinvent the wheel again, but we can use the existing > applications out there as frontends. > So I think with tmnav/panckoucke we have the "frontend framework" that you mentioned, but at the > time it is not in a state that allows to adapt a web-frontend easily. > > So what can we do? > One way is to develop both, the web-frontends and other frontends on base of the panckoucke-Library. > But this means a lot of communication between the developers to find out what is needed and to > develop the interfaces. And it takes more time to develop easy-to-use applications. > > Another way is to develop both, tmnav with panckoucke as general approach, and tm4web as special > web-frontend framework for tm4j. And maybe try to put them together in the far future. > But this means to do some work double. > > I do not know what's the best solution. But I think we should try to find out, what are the special > demands of web applications that use tm4j and if panckoucke is/will be able to fullful this > demands or if we need another approach. I'm very new to the tmnav-Team, so it is possible that > it is not all correct that I said about the goals/abilities of panckoucke. I hope Niko or Christoph > will correct it or write their own opinion about it. > > Bye > > Martin > > > > Florian G. Haas wrote: > > Hello everyone. > > > > On Thursday 23 January 2003 17:02, Jack Park wrote: > > | My view is, therefore, that we must strive to complete the ensemble of Web > > | applications available in Java, and do so with topic maps as the > > | underlying, centralizing glue that binds. TM4J strikes me as a powerful way > > | to make that happen. What the world (according to Park) is waiting for is > > | a light-switch easy Webportal engine built around topic maps. No user of > > | that engine should ever have to touch HTML, XML, XTM, or any such > > | technology unless they want to. Zope/Plone is very close (but, no cigar > > | quite yet) to that level of development. > > > > Permit me to add something along these lines. Cocoon, for example, is great > > but it's of course far from being "light switch easy" as Jack puts it. > > Downloading and installing Cocoon, and getting it running, is a snap, and > > looking at the samples and config files you just get this "wow, this is > > really neat" kind of feeling. But if you're trying to go beyond the sample > > applications and the trivial "Hello World" stuff, well, it's a different > > story. As for my part, I've been trying to set up a simple processing > > environment for all the documentation I write using DocBook, with a tiny web > > GUI for the purpose of customizing Norm Walsh's docbook-xsl stylesheet > > collection (setting parameters, overriding templates etc.). And much to my > > despair, I failed miserably and decided I'd better go back to tweak my ANT > > build environment, which is the approach I've followed ever since. > > > > Now, as much as I'd like a ready-made DocBook XML processing environment > > pluggable into Cocoon, an XTM processing environment should be just as > > wonderful to have. I think TM4J has already taken the right steps in the > > right direction with the approach of defining a set of interfaces to interact > > with any number of back-ends. What TM4web should now do, in my very humble > > opinion, is provide the connection to the other end, the whole > > user-interaction layer. Providing XSL stylesheets for XSLT transformation > > environments is one approach, Velocity templates for servlet-based > > applications another, and GUI tools a third (insert as many others as your > > imagination allows). > > > > If we were to define a set of guidelines describing a TM4J frontend just as > > the engine prescribes the guidelines for the various backends, I think that > > might get us where we want to go. It is, of course, a whole lot more > > difficult to do this on the user end -- as for the backends, a formal > > definition structure is provided by the use of Java interfaces. It's > > comparatively easy to say, this backend is TM4J 'compatible' or not -- if it > > implements the interfaces, it is, if it doesn't it's not. On the front end, > > it's a different story. When is a set of Cocoon generators, pipelines, and > > transformers (or a bunch of Velocity templates, etc. etc.) "a TM4J frontend"? > > > > I believe if we had such guidelines, that could be the glue that holds a > > "frontend framework" (call it TM4web or else) together. > > > > I'm afraid that this might sound all a little like PHB-ish, commercial > > software development style, "project charter" gibberish. I also understand > > that this calls for providing and maintaining high-quality (albeit perhaps > > not even very extensive, I stress that's "quality", not "quantity"). And I > > understand that my reasoning here is certainly influenced by my own > > non-strict-coder background. All in all, I realize that perhaps you'll hate > > it. :-) > > > > Worse still, I don't know any formal approach to defining such a set of > > guidelines. Anybody have experience with regard to this? Would one have to > > define it in prose (such as an authoritative "TM4J frontend designer's > > guide"), or is there something more efficient that perhaps even code > > generators could work with? > > > > My humble own bottom line is this: if we get the TM4J frontends to march in > > step the way the backends do (well, except the DOM backend, for lack of time > > on my part, mea culpa :-( ), this would really be something that could give > > potential users a chance to just *try TM4J out* without having to write code > > themselves or resort to JUnit test cases. In other words, we would move from > > appealing to developers to appealing to users. Plus, we would contribute > > enormously to projects like Cocoon or Axis or perhaps Xindice who seem to be > > suffering from similar symptoms of users asking "OK, I see this is great, but > > What's In It For Me?" > > > > Or am I perhaps missing the point here completely? :-) > > -- Florian > > > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Tm4j-developers mailing list > > Tm4...@li... > > https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Tm4j-users mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-users > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X