You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/02/22 11:11:43 UTC
Re: Cocoon Vision (was: How to edit,delete data on xml file or databa ses?)
On Thu, Feb 22, 2001 at 09:15:10AM +0100, Oliver Klinger wrote:
> Hello out there,
>
> well, in my opinion, Cocoon is THE framework for webpublishing of the
> future! And that is mainly due to the ides and concept that's behind Cocoon.
>
> But I don't think, that database-driven web applications will completely be
> replaced by XML applications, but that the landscape on the web will become
> more homogenious. XML will become an interface language that has the
> capability to interconnect the most different data applications you can
> imagine and to exchange data between this applications. Cocoon I see as an
> universal adapter where you can plug in nearly every application you think
> of, the applications will be reduced to modules that can be used
> interchangeably. Cocoon as a framework controls all these applications, be
> they databases, LDAP directories, word processors, content management
> systems, community portals or whatever and serves as a single end-user
> interface for an all-in-one application consisting of what today are 3, 4,
> 5, or more single applications. In future it doesn't matter, if in this
> all-in-one application there is an ORACLE database or Tamino lying
> underneath, the sub-applications are modules, that can easily be replaced by
> another module.
>
> This is MY vision Cocoon and the future of XML.
That's almost exactly what Prowler is meant to be, I think :)
"Prowler is a 100% pure Java Content Management Framework that allows to access
the content of heterogenous data sources via one uniform transactional XML
interface to build complex web and non-web applications. It provides the
programmer a hierarchical XML filesystem, that can contain the content of
virtual any back-end system."
-- http://www.infozone-group.org/projects2.html#topic1
IMO, Cocoon is about separation of Content from Logic from Presentation. What
you're describing is a *content* management framework, which Cocoon ain't. But
it's an impressive vision nonetheless:) Thanks for airing it.
--Jeff
> Comments highly appreciated.
>
> Regards,
> Oliver
>
[snip Oscar & Simone]
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> Then perhaps you mean integration *framework*, rather? in which case I'm sure
> you're right.
However you want to call it, EAI basically means putting a wrapper
around your legacy applications. As of today that means an unspecified
XML wrapper, tomorrow it may be UDDI. The only technology I'm aware of
that allows you to do that is Cocoon. Perl is not end-to-end XML and
therefore does not belong in this category.
We could argue whether end-to-end XML was necessary or even good and in
that discussion we could bring Perl back into the picture.
> > - does not support client-side processing of XSL stylesheets
>
> Is the C2 model flexible enough to defer formatting to the client side?
Personally I think client-side stylesheet processing is a red herring
and will be extremely unpopular with business web sites. Just like with
Java, XML will rule the server, but not necessarily the client.
> > I believe the right way to do my things is end-to-end XML and everything
> > I use has to subscribe to that paradigm and therefore to Cocoon.
>
> ..or to .NET ;) XML is pleasantly framework-agnostic.
.NET is not end-to-end XML either :) Plus, I don't think anyone would
want to rely on Microsoft upholding the standards :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 26 Feb 2001, Jeff Turner wrote:
> > I just came back from XML DevCon 2001 in London and the folks there
> > agreed that XSP is Cocoon's crown jewels and the disadvantages of Cocoon
> > lie elsewhere:
> >
> > - does not support client-side processing of XSL stylesheets
>
> Is the C2 model flexible enough to defer formatting to the client side?
in a word - yes. the C2 model is flexible enough to deliver toast along
with your page.
- donald
Re: Cocoon Vision (was: How to edit,delete data on xml file or databases?)
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Feb 26, 2001 at 12:30:23PM +0000, Ulrich Mayring wrote:
> Jeff Turner wrote:
> >
[snip]
> > Not that I hold any of this against Cocoon.. just that "natural integration
> > technology" is a title more suited to something generic, evolutionary and
> > amoeba-like (Turbine?) rather than focused and visionary.
>
> Do you know any better integration technology than Cocoon?
Perl? ;) Now if I were Matt Sargeant, I could give you an impressive lecture
about the univerality, XML support and overall coolness of Perl. It's been
called "the duct tape of the Internet". Integration technology indeed!
> There simply is no other end-to-end XML technology out there. And I doubt
> non-XML based technologies are going anywhere in the future.
Then perhaps you mean integration *framework*, rather? in which case I'm sure
you're right.
> I just came back from XML DevCon 2001 in London and the folks there
> agreed that XSP is Cocoon's crown jewels and the disadvantages of Cocoon
> lie elsewhere:
>
> - does not support client-side processing of XSL stylesheets
Is the C2 model flexible enough to defer formatting to the client side?
> - performance
> - our developers aren't used to end-to-end XML, they only know
> CGI/JSP/whatever
>
> I believe the right way to do my things is end-to-end XML and everything
> I use has to subscribe to that paradigm and therefore to Cocoon.
..or to .NET ;) XML is pleasantly framework-agnostic.
--Jeff
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
Re: Cocoon Vision (was: How to edit,delete data on xml file or databases?)
Posted by S�rgio Carvalho <sc...@criticalsoftware.com>.
On Mon, 26 Feb 2001 12:30:23 +0000
Ulrich Mayring <ul...@denic.de> wrote:
> - does not support client-side processing of XSL stylesheets
AFAIK, all you have to do is deliver a text/xml document with a stylesheet PI inside, and provide HTTP access to the stylesheet. Why can't you do that with Cocoon?
--
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com
If at first you don't succeed, skydiving is not for you
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 26 Feb 2001, Steve Muench wrote:
> IE5 with the MSXSL3 engine installed. Unfortunately, I've checked
> with friends at Microsoft and to date I haven't been able to
> divine a technique to detect the difference between an IE5 browser
> that is using the "older" pre-XSLT-1.0-compatible engine versus
> one that is using the MSXSL3 engine that is XSLT 1.0 compatible.
that's also whacked.
> | simply send the xml page with the xml-stylesheet pi but don't invoke
> | the xslt processor. or are you suggesting that it should occur at a
> | lower level automagically somehow?
>
> Would this be indicated in the PI itself, or done via code?
you'd do it by not generaing a cocoon-process type="xslt" PI.
- donald
Re: Cocoon Vision (was: How to edit,delete data on xml file or databases?)
Posted by Steve Muench <St...@oracle.com>.
| > I just came back from XML DevCon 2001 in London and the folks there
| > agreed that XSP is Cocoon's crown jewels and the disadvantages of Cocoon
| > lie elsewhere:
| >
| > - does not support client-side processing of XSL stylesheets
|
| but that's whacked - cocoon does support this. if you detect a user-agent
| that happens to support xslt (are there any yet?),
IE5 with the MSXSL3 engine installed. Unfortunately, I've checked
with friends at Microsoft and to date I haven't been able to
divine a technique to detect the difference between an IE5 browser
that is using the "older" pre-XSLT-1.0-compatible engine versus
one that is using the MSXSL3 engine that is XSLT 1.0 compatible.
Ugh. It might have been forward-thinking to plop some gem of info
in the user agent to let server-side software sniff this important
distinction out, but seems that it was not possible or not thought of.
I think the only thing you can fall back on is that the MSXSL3 engine
still supports the "older" pre-XSLT-1.0 syntax (based on the namespace
URI found in the stylesheet), so alas the only workable solution
it appears is to continue to author parallel stylesheets, one for
server-side XSLT 1.0 and one for browser-side pre-XSLT-1.0-MS-Dialect
which is yucky. Once a version of IE ships that has the MSXSL3 pre-installed,
then sniffing that version in the user-agent will solve this problem.
| simply send the xml page with the xml-stylesheet pi but don't invoke
| the xslt processor. or are you suggesting that it should occur at a
| lower level automagically somehow?
Would this be indicated in the PI itself, or done via code?
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
Re: Cocoon Vision (was: How to edit,delete data on xml file or databases?)
Posted by Paul Russell <pa...@luminas.co.uk>.
* Donald Ball (balld@webslingerZ.com) wrote :
> > Still, it won't take off. Two polemics why not:
> >
> > - Yahoo doesn't want me to filter out the ad banners with my own local
> > stylesheet
> > - Java didn't work on the client either
> damned good points.
Quite. Also, I'm not sure that there's necessarily any benefit until
browsers actually 'understand' the data. Browsers are purely a
presentation engine, at the end of the day, controvertial though that
idea is.
One day, we won't have HTML, we'll have properly marked up content that
allows the browser to actually understand the structure of the document,
and present it to the user by getting this information to the user
through any sensible medium. 'Course, we'll have semantic search and a
fully distributed, trust metric, secure, payment enabled, fully buzword
compliant 'web' by then too :)
P.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 27 Feb 2001, Uli Mayring wrote:
> On Mon, 26 Feb 2001, Donald Ball wrote:
>
> > i know i'm preaching to the choir, but what the hell. how long do you
> > reckon it's going to be before xml/xslt capable clients have dominant
> > market share (95%+)? suggest not holding your breath while waiting.
>
> Actually it was said that the current version of IE and the next version
> of Netscape would support it. That would mean a useful market share
> sometime this year.
as if everyone's going to upgrade en masse! c'mon, that's just wishful
thinking.
> Still, it won't take off. Two polemics why not:
>
> - Yahoo doesn't want me to filter out the ad banners with my own local
> stylesheet
> - Java didn't work on the client either
damned good points.
- donald
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Uli Mayring <ul...@denic.de>.
On Mon, 26 Feb 2001, Donald Ball wrote:
> i know i'm preaching to the choir, but what the hell. how long do you
> reckon it's going to be before xml/xslt capable clients have dominant
> market share (95%+)? suggest not holding your breath while waiting.
Actually it was said that the current version of IE and the next version
of Netscape would support it. That would mean a useful market share
sometime this year. Still, it won't take off. Two polemics why not:
- Yahoo doesn't want me to filter out the ad banners with my own local
stylesheet
- Java didn't work on the client either
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 26 Feb 2001, Uli Mayring wrote:
> On Mon, 26 Feb 2001, Donald Ball wrote:
>
> > > - does not support client-side processing of XSL stylesheets
> >
> > but that's whacked - cocoon does support this. if you detect a user-agent
> > that happens to support xslt (are there any yet?), simply send the xml
> > page with the xml-stylesheet pi but don't invoke the xslt processor. or
> > are you suggesting that it should occur at a lower level automagically
> > somehow?
>
> At a higher level, I suppose, let me explain.
>
> Most of the people on XML DevCon did not know too much about cocoon, with
> some notable exceptions like James Tauber. The argument against cocoon was
> meant more as a general criticism that cocoon would focus too much on the
> server and not enough on client-side technologies.
i know i'm preaching to the choir, but what the hell. how long do you
reckon it's going to be before xml/xslt capable clients have dominant
market share (95%+)? suggest not holding your breath while waiting.
- donald
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Uli Mayring <ul...@denic.de>.
On Mon, 26 Feb 2001, Donald Ball wrote:
> > - does not support client-side processing of XSL stylesheets
>
> but that's whacked - cocoon does support this. if you detect a user-agent
> that happens to support xslt (are there any yet?), simply send the xml
> page with the xml-stylesheet pi but don't invoke the xslt processor. or
> are you suggesting that it should occur at a lower level automagically
> somehow?
At a higher level, I suppose, let me explain.
Most of the people on XML DevCon did not know too much about cocoon, with
some notable exceptions like James Tauber. The argument against cocoon was
meant more as a general criticism that cocoon would focus too much on the
server and not enough on client-side technologies.
The aforementioned stylesheet issue was mentioned as an example. The
argument goes that the thing of the future will be XML gateways, which are
a combination of proxy/load balancer/XML wrapper. These gateways will make
the decision based on the user agent, server-side technologies are only
expected to produce data, the gateway will then slap angle brackets
around it. Cocoon's own mechanism - which I'm not sure is known to many of
the people I talked with - and many of its publishing capabilities are
deemed unnecessary in the light of these XML gateways.
Now, I think most of these arguments are baloney, but that is what people
said. I may have talked to an unrepresentative sample of the XML
population, though :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 26 Feb 2001, Ulrich Mayring wrote:
> I just came back from XML DevCon 2001 in London and the folks there
> agreed that XSP is Cocoon's crown jewels and the disadvantages of Cocoon
> lie elsewhere:
>
> - does not support client-side processing of XSL stylesheets
but that's whacked - cocoon does support this. if you detect a user-agent
that happens to support xslt (are there any yet?), simply send the xml
page with the xml-stylesheet pi but don't invoke the xslt processor. or
are you suggesting that it should occur at a lower level automagically
somehow?
- donald
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> Hmm.. I don't know how great Cocoon is as "integration technology". Source
> input has to be producer-generated XML. Importing XML from the rest of the
> world (CGI scripts) is officially Frowned Upon. For logic, there's only XSP.
> Taglibs are very exotic fish in the server-side ocean. For presentation, Cocoon
> rocks, as long as you've got very clued-up designers who like XSLT ;)
Designers are irrelevant in the world of EAI, this is the domain of IT
and business people. They're not going to ask designers for input on
their EAI project, this is much bigger than just websites :)
To the effect that for logic there is "only" XSP - what more could you
want? Assuming you're using Java for EAI (who isn't these days?) XSP is
a natural fit.
> Not that I hold any of this against Cocoon.. just that "natural integration
> technology" is a title more suited to something generic, evolutionary and
> amoeba-like (Turbine?) rather than focused and visionary.
Do you know any better integration technology than Cocoon? There simply
is no other end-to-end XML technology out there. And I doubt non-XML
based technologies are going anywhere in the future.
I just came back from XML DevCon 2001 in London and the folks there
agreed that XSP is Cocoon's crown jewels and the disadvantages of Cocoon
lie elsewhere:
- does not support client-side processing of XSL stylesheets
- performance
- our developers aren't used to end-to-end XML, they only know
CGI/JSP/whatever
I believe the right way to do my things is end-to-end XML and everything
I use has to subscribe to that paradigm and therefore to Cocoon.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 26 Feb 2001, Jeff Turner wrote:
> Hmm.. I don't know how great Cocoon is as "integration technology". Source
> input has to be producer-generated XML. Importing XML from the rest of the
> world (CGI scripts) is officially Frowned Upon. For logic, there's only XSP.
that's not true at all! importing data from the rest of the world is _key_
- there are just constraints on how you go about doing it. cocoon isn't
simply a filter you slap on the end of a cgi or servlet chain - it must
actively request the xml data from the outside world - which you can
_easily_ do by any of a number of mechanisms without even getting your
fingers dirty with xsp.
- donald
Re: Cocoon Vision (was: How to edit,delete data on xml file or databases?)
Posted by Jeff Turner <je...@socialchange.net.au>.
Hmm.. I don't know how great Cocoon is as "integration technology". Source
input has to be producer-generated XML. Importing XML from the rest of the
world (CGI scripts) is officially Frowned Upon. For logic, there's only XSP.
Taglibs are very exotic fish in the server-side ocean. For presentation, Cocoon
rocks, as long as you've got very clued-up designers who like XSLT ;)
Not that I hold any of this against Cocoon.. just that "natural integration
technology" is a title more suited to something generic, evolutionary and
amoeba-like (Turbine?) rather than focused and visionary.
Schema Adjunct Framework looks useful. For the interested, this is worth a
read:
http://ep.open.ac.uk/PubSys/docs/extreme-xml/html/vort0209.html
--Jeff
On Mon, Feb 26, 2001 at 10:36:57AM +0000, Ulrich Mayring wrote:
> Jeff Turner wrote:
> >
> > IMO, Cocoon is about separation of Content from Logic from Presentation. What
> > you're describing is a *content* management framework, which Cocoon ain't. But
> > it's an impressive vision nonetheless:) Thanks for airing it.
>
> Cocoon provides a way to plug-in arbitrary functionality via XSP. That
> is the crown jewels of cocoon and that is what other components IMHO
> have to stack up against. Meaning that if you have an application that
> does not - like cocoon - cleanly seperates logic, presentation and
> content, then it won't be pluggable and thus won't be used (with
> cocoon). The wrong way would be IMHO to try to plug Cocoon into another
> application - all cocoon does is provide a publishing framework and as
> such it is naturally the highest level of any application.
>
> Slapping XML interfaces onto legacy (and new) applications will be huge
> and Cocoon is the natural integration technology. XML Schema will play a
> huge part in application development, the only remaining question is
> whether the W3C will at some point provide a standard for app
> development (like Schema Adjunct Framework) or whether things will come
> out of the open source community.
>
> All IMHO of course,
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
--
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeff Turner wrote:
>
> IMO, Cocoon is about separation of Content from Logic from Presentation. What
> you're describing is a *content* management framework, which Cocoon ain't. But
> it's an impressive vision nonetheless:) Thanks for airing it.
Cocoon provides a way to plug-in arbitrary functionality via XSP. That
is the crown jewels of cocoon and that is what other components IMHO
have to stack up against. Meaning that if you have an application that
does not - like cocoon - cleanly seperates logic, presentation and
content, then it won't be pluggable and thus won't be used (with
cocoon). The wrong way would be IMHO to try to plug Cocoon into another
application - all cocoon does is provide a publishing framework and as
such it is naturally the highest level of any application.
Slapping XML interfaces onto legacy (and new) applications will be huge
and Cocoon is the natural integration technology. XML Schema will play a
huge part in application development, the only remaining question is
whether the W3C will at some point provide a standard for app
development (like Schema Adjunct Framework) or whether things will come
out of the open source community.
All IMHO of course,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re[2]: Cocoon Vision (was: How to edit,delete data on xml file or databa ses?)
Posted by Sandor Spruit <sa...@cs.uu.nl>.
Sérgio,
On Monday, February 26, 2001, 12:23:19 PM, you wrote:
Sérgio> On Thu, 22 Feb 2001 21:11:43 +1100
Sérgio> Jeff Turner <je...@socialchange.net.au> wrote:
Sérgio> <snip/>
>>
>> IMO, Cocoon is about separation of Content from Logic from
>> Presentation. What you're describing is a *content* management
>> framework, which Cocoon ain't. But it's an impressive vision
>> nonetheless:) Thanks for airing it.
Sérgio> I disagree. Cocoon is definitely entering the content
Sérgio> management scenario, even if it was not its original target.
You are right, just look at the information on Cocoon 2 !
Sérgio> If all Cocoon did was separation of Content from Logic from
Sérgio> Presentation, I would not use it, but rather a combination of
Sérgio> Enterprise Javabeans, XML-generating Java server pages and an
Sérgio> XSLT engine (probably built as a module on the web server).
Sérgio> Other solutions exist, most showing this separation into
Sérgio> "business logic", "application logic" and "presentation". All
Sérgio> show the same problem: They are not fully adapted to the
Sérgio> domain of web applications. One can easily imagine writing the
Sérgio> same patterns over and over without any possible means of
Sérgio> reduction.
Agreed.
>>From my use of C1, and recent experiments with C2, I'd say Cocoon
>>distils very common patterns (like content aggregation) into
>>something I can just name a content management system. Something
>>that has a central document (the sitemap), where a site is described
>>as the composition of a lot of reusable parts, can only be called a
>>CMS.
Right.
Sérgio> I've written this before, in this list: I'd rather see Cocoon
Sérgio> focus on being a very easy to use CMS, that provides easily
Sérgio> available, commonly used, patterns for web programming, while
Sérgio> leaving specific business logic and application logic
Sérgio> facilities to other systems such as EJB containers - by means
Sérgio> of RPC protocols such as SOAP, XML-RPC, Corba, DCOM, ... It
Sérgio> doesn't hurt, having data-processing abilites, like XSPs, but
Sérgio> that is not Cocoon's strongest point and it is not the reason
Sérgio> I chose it as the web application platform of choice.
Agreed 100%. The XSP thing is nice for some basic manipulations, but
it's the one point in Cocoon where you get some potentially confusing
combinations of Java code and XML.
I'm currently looking at various ideas to build CMS-like facilities
around, on-top or along-side Cocoon's pipeline for XML processing -
which works very nice indeed. Then stear the output of Cocoon through
a JetSpeed portlet and you have a really nice, clean (!) system, IMHO.
Regards,
Sandor
--
ir A.G.L. Spruit, Utrecht University, the Netherlands
Institute of information and computing sciences
"There is a bit of magic in everything, and then some
loss to even things out" (from: Lou Reed, "Magic and Loss")
Re: Cocoon Vision (was: How to edit,delete data on xml file or databa ses?)
Posted by S�rgio Carvalho <sc...@criticalsoftware.com>.
On Thu, 22 Feb 2001 21:11:43 +1100
Jeff Turner <je...@socialchange.net.au> wrote:
<snip/>
>
> IMO, Cocoon is about separation of Content from Logic from Presentation. What
> you're describing is a *content* management framework, which Cocoon ain't. But
> it's an impressive vision nonetheless:) Thanks for airing it.
I disagree. Cocoon is definitely entering the content management scenario, even if it was not its original target.
If all Cocoon did was separation of Content from Logic from Presentation, I would not use it, but rather a combination of Enterprise Javabeans, XML-generating Java server pages and an XSLT engine (probably built as a module on the web server).
Other solutions exist, most showing this separation into "business logic", "application logic" and "presentation". All show the same problem: They are not fully adapted to the domain of web applications. One can easily imagine writing the same patterns over and over without any possible means of reduction.
Prowler CMS (was: Re[2]: Cocoon Vision (was: How to edit ...)
Posted by Sandor Spruit <sa...@cs.uu.nl>.
Jeff,
On Thursday, February 22, 2001, 11:11:43 AM, you wrote:
Jeff> On Thu, Feb 22, 2001 at 09:15:10AM +0100, Oliver Klinger wrote:
[large snip of interesting "vision" stuff]
Jeff> That's almost exactly what Prowler is meant to be, I think :)
Jeff> "Prowler is a 100% pure Java Content Management Framework that
Jeff> allows to access the content of heterogenous data sources via
Jeff> one uniform transactional XML interface to build complex web and
Jeff> non-web applications. It provides the programmer a hierarchical
Jeff> XML filesystem, that can contain the content of virtual any
Jeff> back-end system."
Jeff> -- http://www.infozone-group.org/projects2.html#topic1
Jeff> IMO, Cocoon is about separation of Content from Logic from
Jeff> Presentation. What you're describing is a *content* management
Jeff> framework, which Cocoon ain't. But it's an impressive vision
Jeff> nonetheless:) Thanks for airing it.
Do you have any experience with Prowler ? Any comments ? What I'm very
interested in, is what the overall architecture looks like.
How do the Prowler, Cocoon and JetSpeed combine, to be more specific ?
(let's hope someone out there swallows the bait ;)
Cheers,
Sandor
--
ir A.G.L. Spruit, Utrecht University, the Netherlands
Institute of information and computing sciences
"There is a bit of magic in everything, and then some
loss to even things out" (from: Lou Reed, "Magic and Loss")