cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davies" <>
Subject Re: Happy to be wrong!
Date Fri, 28 Jan 2000 16:01:53 GMT
This really clarifies the issue.
A Web Publishing Framework seems to me the more important thing at this
time. There'll be armies of developers jumping on applications extrensions
when a robust publishing framework is in place, but only a few capable of
creating the latter (such as you guys).
There's a grey area in the middle, though.
That is -- not glossing over any ambiguities putting it this way -- what
developers need most in an XML/XSL framework, I think (on top of the very
significant general all-browser document binding Cocoon provides), is an
engine prefigured to serve the XML description statements pertinent to their
applications, whether CML, MathML, SMIL, SQL, XLink, and so on. Just
contained DTD bundles, perhaps -- but in another sense the publishing
framework become a full application server. In the same way ColdFusion
bundles a broad set of description statements, and the capability of custom
applications extensions, but is first (I think!?) a publishing framework.


----- Original Message -----
From: "Ted" <>
To: <>
Sent: Friday, January 28, 2000 10:24 AM
Subject: Re: Happy to be wrong!

> Stefano, if I may take a stab at this from a different point of view?
> Cocoon's raison d'etre is as a Web Publishing Framework. I think as
> developers, we tend to forget this, and we are pushing Cocoon to be an
> Application Development Framework. A clear example of this is the xBugs
> proposal, which is an app. I am not saying that it can't be an app dev
> framework (au contraire, I think it can develop into a kick-ass one).
> These two directions have different needs. Publishing is more
> output-oriented from a user's point of view, and therefore, the E-XSLT
> direction makes sense. You can have:
> XML -->(Whatever transformation you want, XSLT, E-XSLT)---->XML
> App Dev, on the other hand, has a balance of input and output from a
> user's point of view. I think, here is were Ricardo's taglibs make
> sense, for the App Developer. You can have:
> XML1 Input -->servlet-->Dynamically-generated XML0 (using classic XSP or
> via taglibs in XSL) -->XSLT-->XML1 Output
> XML1 can be WML, VML, XHTML or whatever. Groups can contribute taglibs
> for this cause, which become lego blocks of the app dev framework (SQL,
> Mail, etc).
> Each seem to have its own place, but within its own framework ---
> publishing or app dev. I agree with Pier. It may take a while to marry
> them, but they can be married.
> Ted
> Chaos has bifurcated.
> Stefano Mazzocchi wrote:
> >
> > Have you ever been happy to be wrong?
> >
> > Of course, not always, but sometimes it feels good to see something that
> > you were missing before and understanding that doing this you saved lots
> > of pain and wasted resources.
> >
> > Federico and I went to dinner out tonight and we came to the conclusion
> > than the XSP specification can be _totally_ represented as an
> > Extended-XSLT taglib. Nothing of what I've previously said is true: you
> > gain nothing by using XSP.
> >
> > The problem I had was driven by the "stylesheet compilation" idea. I'll
> > will explain shortly why I think this is misleading and I will also
> > explain this in a moment.
> >
> > As you all know, the XSP idea came after seeing lots of holes in JSP
> > support for XML. This doesn't go away. JSP cannot be used inside Cocoon
> > and this won't change soon.
> >
> > Ok, let's move on: this is the XSP model how I imagined it
> >
> >  XML -XSLT-> XSP -something-> Java -javac-> Class -execution-> XML
> >
> > Ricardo added something and this is how it's done today
> >
> >  XML -XSLT-taglibs-> XSP -XSLT-> java -javac-> producer -execution->
> >
> > Many proposed the use of E-XSLT to do the same thing... my concerns
> > where due mainly to performance reasons but they went away... let'
> > see... you suggest to do something like this
> >
> >
> > as you see, there is a topological equivalence between the two, being
> > the XSP model, a way to express how an E-XSLT engine should work
> > internally. This was not clear when I designed XSP since it was Ricardo
> > that added the namespace-taglib driven idea to the XSP spec. This
> > completely changed the picture.
> >
> > The only concern I had, was still performance: how can EXSLT work faster
> > than a compiled server page? simple, it can't.
> >
> > Scott proposed stylesheet compilation as a solution: but in my mind I
> > could not see how compiling a stylesheet would help... true, you could
> > simplify many things and do faster transformations but you still had to
> > do XML parsing, events feeding, tree creation and evaluation and a bunch
> > of stuff...
> >
> > Tonight, Federico opened my eyes (man, I'll miss that guy! these
> > exoffice mean men are stealing all my friends, damn it! :)
> >
> > A smart E-XSLT engine should _not_ perform stylesheet compilation (which
> > may be helpful but no that much), but do _page_ compilation. Let's look
> > again:
> >
> >  XML -EXSLT-> Java -javac-> producer -execution-> XML
> >
> > so, if we evaluate the two with what Cocoon does today we get
> >
> >  -EXSLT-> := -XSLT-taglibs-> XSP -XSLT->
> >
> > which makes XSP totally useless since it's just a step between XSLT
> > transformations.
> >
> > QED :)
> >
> > NOTE: I still like the ability to use XSP as a taglib for direct code
> > inclusion inside a page, it may be helpful.
> >
> > Anyway, I'll happily let Ricardo and all you other XSLT experts figure
> > out the way to make the above possible, but I've been finally convinced
> > and I'm a happy guy now :)
> >
> > --
> > Stefano Mazzocchi      One must still have chaos in oneself to be
> >                           able to give birth to a dancing star.
> > <>                             Friedrich Nietzsche
> > --------------------------------------------------------------------
> >  Come to the first official Apache Software Foundation Conference!
> > ------------------------- http://ApacheCon.Com ---------------------

View raw message