You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ulrich Mayring <ul...@denic.de> on 2001/02/26 11:36:57 UTC
Re: Cocoon Vision (was: How to edit,delete data on xml file or
databases?)
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: 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>
--