You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/01/28 00:33:15 UTC
Happy to be wrong!
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-> XML
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's
see... you suggest to do something like this
XML -EXSLT-> XML
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: Happy to be wrong!
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Stefano Mazzocchi wrote:
>
> Tonight, Federico opened my eyes (man, I'll miss that guy! these
> exoffice mean men are stealing all my friends, damn it! :)
PLUR :) We're just preparing the friendliest environment for when you'll
join after your graduation :) hahahahahahahahahaha :)
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Happy to be wrong!
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: Paul Davies <pd...@cgocable.net>
To: <co...@xml.apache.org>
Sent: Friday, January 28, 2000 5:01 PM
Subject: Re: Happy to be wrong!
> 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).
Perhaps, but nowadays, all Web sites are or will become dynamic. The fashion
is : let your sites be "intelligent" (that is : serving content depending on
the client profile), and for this, sites need to be dynamic...
If you want people to use Cocoon, you need also (and quickly) to design a
(robust) dynamic architecture.
Eric.
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
----------------------------------------------------------------------------
-----------------------------
Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
_______________________________________
Re: Happy to be wrong!
Posted by Paul Davies <pd...@cgocable.net>.
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.
Paul
----- Original Message -----
From: "Ted" <te...@gs2admin1.e-meet.com>
To: <co...@xml.apache.org>
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-> XML
> >
> > 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
> >
> > XML -EXSLT-> XML
> >
> > 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.
> > <st...@apache.org> Friedrich Nietzsche
> > --------------------------------------------------------------------
> > Come to the first official Apache Software Foundation Conference!
> > ------------------------- http://ApacheCon.Com ---------------------
>
Re: Happy to be wrong!
Posted by Steve Muench <sm...@us.oracle.com>.
Like XSP "tags" any/all XSLT extensions elements can:
(*) Optionally do arbitrary processing
(*) Optionally write something to result page
This is a pretty open-ended model that doesn't
pin you into publishing versus app development.
you might argue that in the appdevelopment
scenario the "arbitrary processing part"
plays a bigger role, perhaps writing nothing
into the result page, but any combination is
possible.
_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: "Ted" <te...@gs2admin1.e-meet.com>
To: <co...@xml.apache.org>
Sent: Friday, January 28, 2000 7: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-> XML
| >
| > 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
| >
| > XML -EXSLT-> XML
| >
| > 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.
| > <st...@apache.org> Friedrich Nietzsche
| > --------------------------------------------------------------------
| > Come to the first official Apache Software Foundation Conference!
| > ------------------------- http://ApacheCon.Com ---------------------
|
Re: Happy to be wrong!
Posted by Ted <te...@gs2admin1.e-meet.com>.
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-> XML
>
> 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
>
> XML -EXSLT-> XML
>
> 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.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
Re: Happy to be wrong!
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Niclas Hedhman wrote:
>
> Could you two keep the private "encouragements" off-list...
> It radiates the wrong atmosphere to newcomers.
Sorry about that :) It'll never happen again :)
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Happy to be wrong!
Posted by Ben Laurie <be...@algroup.co.uk>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > If this is "radiating the wrong atmosphere to newcomers"... well, I like
> > its practical results.
> >
> > Anyway, I agree we went a little bit too much down the line... sorry
> > about that.
>
> Nothing wrong with the joking, but calling each other names is a bit much.
> That's all.
At least they only said "dork" and "moron". I got called an "ignorant
slut" on the new-httpd list once. :-)
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt
Re: Happy to be wrong!
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> If this is "radiating the wrong atmosphere to newcomers"... well, I like
> its practical results.
>
> Anyway, I agree we went a little bit too much down the line... sorry
> about that.
Nothing wrong with the joking, but calling each other names is a bit much.
That's all.
Niclas
Re: Happy to be wrong!
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Pierpaolo Fumagalli wrote:
>
> > Stefano Mazzocchi wrote:
> > > > Nope... :) It makes me feel like a dork :)
> > > You _are_ a dork, that's why :)
> > Thanks :) (moron!)
>
> Could you two keep the private "encouragements" off-list...
> It radiates the wrong atmosphere to newcomers.
I modestly think the opposite... I've made lots of friends on these mail
lists and joking is the best way to set up a fun substrate to work with.
Man, we've been doing this for almost 2 and 1/2 years... after pier, jon
and myself took over the jserv mail list which such an attitude (before
it was _way_ more serious and boring) we grew the jserv project from 200
of a single list to 20 projects and thousands of people on all the mail
lists.
If this is "radiating the wrong atmosphere to newcomers"... well, I like
its practical results.
Anyway, I agree we went a little bit too much down the line... sorry
about that.
Stefano.
Re: Happy to be wrong!
Posted by Niclas Hedhman <ni...@localbar.com>.
Pierpaolo Fumagalli wrote:
> Stefano Mazzocchi wrote:
> > > Nope... :) It makes me feel like a dork :)
> > You _are_ a dork, that's why :)
> Thanks :) (moron!)
Could you two keep the private "encouragements" off-list...
It radiates the wrong atmosphere to newcomers.
Niclas
Re: Happy to be wrong!
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Stefano Mazzocchi wrote:
>
> > > Have you ever been happy to be wrong?
> > Nope... :) It makes me feel like a dork :)
> You _are_ a dork, that's why :)
Thanks :) (moron!)
> > You basically apply the transformation and THEN compile the resulting
> > XML... Did I get it right????
>
> No. That way you come up with a compiled static page.
????
> Ok, suppose you have a page like this
> <p>Good <time:time-of-day/></p>
> where time: is your taglib and gets executed as
> (hour <= 12) ? "morning" : "afternoon"
> (don't look at the logic that sucks)
> the EXSLT output could be either
>
> public class Producer {
> int hour = new Date().getHour();
> void producer (request, response, handler) {
> handler.startDocument();
> handler.createElement("p");
> handler.content("Good ");
> handler.content((hour <= 12) ? "morning" : "afternoon");
> handler.closeElement("p");
> handler.endDocument();
> }
> }
That's what I was thinking... Exactly that...
> or
>
> <?xml version="1.0"?>
> <p>Good [Morning|Afternoon]</p>
>
> depending on what "mode" of operation we choosed: interpretation or
> compilation.
Exactly... Yes... that's what I meant when i said "apply the
transformation"... I should have said "transform it into a java source",
sorry :)(
> See how, in the first case, execution of that class alone, once compiled
> into bytecode, totally skips xml parsing and xslt transformation,
> resulting in a much faster execution.
Yep yep... That's what I was saying...
> Note that "compilaton mode" is exactly what XSP is today, and
> "interpretation mode" is what EXSLT should be. But it's an
> implementation detail (even if a big one) to trigger one behavior or the
> other, not a design decision.
> That is the point where I was wrong.
Agreed....
> Still, the implementation details are a nightmare, but since we already
> have a working XSP implementation, it could not be that bad... but I
> this point, I can't really tell and I'm happy to have others taking care
> of this :)
:) you lazy boy :)
> > I still have to figure out HOW it's possible (from the implementation
> > point of view) but I believe it's possible...
>
> It's time for the "XSLT" folks to come up with something about this :)
(just to let you all know) I AM NOT AN XSLT FOLK :)
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Happy to be wrong!
Posted by Steve Muench <sm...@us.oracle.com>.
|
| It's time for the "XSLT" folks to come up
| with something about this :)
|
Too early to say anything official on this yet, but
as you can imagine existing implementations of
extension-element functionality (Saxon 5.0, Xalan,
and soon OracleXSLT) and extension-element-like
functionality (xsp,cocoon Producer,others?) definitely
will serve as guides to implementation approaches
in any work we may do to refine the details.
I believe Scott's points have been that even in absence
of more specific details, what's in the 1.0 spec can
be used to align the page syntax for content generation
around XSLT Extension Elements, using XSP as a cool
way to design libraries of implementations of extension
elements.
_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
XSL Working Group Rep for Oracle
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, January 28, 2000 3:43 AM
Subject: Re: Happy to be wrong!
| Pierpaolo Fumagalli wrote:
| >
| > This is the "real" answer...
| >
| > Stefano Mazzocchi wrote:
| > >
| > > Have you ever been happy to be wrong?
| >
| > Nope... :) It makes me feel like a dork :)
|
| You _are_ a dork, that's why :)
|
| > [...]
| > > The only concern I had, was still performance: how can EXSLT work faster
| > > than a compiled server page? simple, it can't.
| >
| > That's the point...
|
| Yes.
|
| > > 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.
| >
| > You basically apply the transformation and THEN compile the resulting
| > XML... Did I get it right????
|
| No. That way you come up with a compiled static page.
|
| Ok, suppose you have a page like this
|
| <p>Good <time:time-of-day/></p>
|
| where time: is your taglib and gets executed as
|
| (hour <= 12) ? "morning" : "afternoon"
|
| (don't look at the logic that sucks)
|
| the EXSLT output could be either
|
| public class Producer {
|
| int hour = new Date().getHour();
|
| void producer (request, response, handler) {
| handler.startDocument();
| handler.createElement("p");
| handler.content("Good ");
| handler.content((hour <= 12) ? "morning" : "afternoon");
| handler.closeElement("p");
| handler.endDocument();
| }
| }
|
| or
|
| <?xml version="1.0"?>
| <p>Good [Morning|Afternoon]</p>
|
| depending on what "mode" of operation we choosed: interpretation or
| compilation.
|
| See how, in the first case, execution of that class alone, once compiled
| into bytecode, totally skips xml parsing and xslt transformation,
| resulting in a much faster execution.
|
| Note that "compilaton mode" is exactly what XSP is today, and
| "interpretation mode" is what EXSLT should be. But it's an
| implementation detail (even if a big one) to trigger one behavior or the
| other, not a design decision.
|
| That is the point where I was wrong.
|
| Still, the implementation details are a nightmare, but since we already
| have a working XSP implementation, it could not be that bad... but I
| this point, I can't really tell and I'm happy to have others taking care
| of this :)
|
| > I still have to figure out HOW it's possible (from the implementation
| > point of view) but I believe it's possible...
|
| It's time for the "XSLT" folks to come up with something about this :)
|
| --
| Stefano Mazzocchi One must still have chaos in oneself to be
| able to give birth to a dancing star.
| <st...@apache.org> Friedrich Nietzsche
| --------------------------------------------------------------------
| Come to the first official Apache Software Foundation Conference!
| ------------------------- http://ApacheCon.Com ---------------------
|
|
|
Re: Happy to be wrong!
Posted by Mike Engelhart <me...@earthtrip.com>.
Stefano Mazzocchi wrote:
> (hour <= 12) ? "morning" : "afternoon"
>
> (don't look at the logic that sucks)
>
> the EXSLT output could be either
>
> public class Producer {
>
> int hour = new Date().getHour();
>
> void producer (request, response, handler) {
> handler.startDocument();
> handler.createElement("p");
> handler.content("Good ");
> handler.content((hour <= 12) ? "morning" : "afternoon");
> handler.closeElement("p");
> handler.endDocument();
> }
> }
>
> or
>
> <?xml version="1.0"?>
> <p>Good [Morning|Afternoon]</p>
>
> depending on what "mode" of operation we choosed: interpretation or
> compilation.
>
> See how, in the first case, execution of that class alone, once compiled
> into bytecode, totally skips xml parsing and xslt transformation,
> resulting in a much faster execution.
I'm not sure how you can skip over XSLT transformation by creating a
producer. The XSP generated code I've looked at just adds a PI to tell the
output what xsl sheet to use for transformation, right?? Isn't this exactly
how XSP works today?
Mike
Re: Happy to be wrong!
Posted by Stefano Mazzocchi <st...@apache.org>.
Pierpaolo Fumagalli wrote:
>
> This is the "real" answer...
>
> Stefano Mazzocchi wrote:
> >
> > Have you ever been happy to be wrong?
>
> Nope... :) It makes me feel like a dork :)
You _are_ a dork, that's why :)
> [...]
> > The only concern I had, was still performance: how can EXSLT work faster
> > than a compiled server page? simple, it can't.
>
> That's the point...
Yes.
> > 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.
>
> You basically apply the transformation and THEN compile the resulting
> XML... Did I get it right????
No. That way you come up with a compiled static page.
Ok, suppose you have a page like this
<p>Good <time:time-of-day/></p>
where time: is your taglib and gets executed as
(hour <= 12) ? "morning" : "afternoon"
(don't look at the logic that sucks)
the EXSLT output could be either
public class Producer {
int hour = new Date().getHour();
void producer (request, response, handler) {
handler.startDocument();
handler.createElement("p");
handler.content("Good ");
handler.content((hour <= 12) ? "morning" : "afternoon");
handler.closeElement("p");
handler.endDocument();
}
}
or
<?xml version="1.0"?>
<p>Good [Morning|Afternoon]</p>
depending on what "mode" of operation we choosed: interpretation or
compilation.
See how, in the first case, execution of that class alone, once compiled
into bytecode, totally skips xml parsing and xslt transformation,
resulting in a much faster execution.
Note that "compilaton mode" is exactly what XSP is today, and
"interpretation mode" is what EXSLT should be. But it's an
implementation detail (even if a big one) to trigger one behavior or the
other, not a design decision.
That is the point where I was wrong.
Still, the implementation details are a nightmare, but since we already
have a working XSP implementation, it could not be that bad... but I
this point, I can't really tell and I'm happy to have others taking care
of this :)
> I still have to figure out HOW it's possible (from the implementation
> point of view) but I believe it's possible...
It's time for the "XSLT" folks to come up with something about this :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: Happy to be wrong!
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
This is the "real" answer...
Stefano Mazzocchi wrote:
>
> Have you ever been happy to be wrong?
Nope... :) It makes me feel like a dork :)
> [...]
> 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.
Hmmm... Interesting point... Those Italian nights seems to be still
productive, even in my absence :)
> [...]
> The only concern I had, was still performance: how can EXSLT work faster
> than a compiled server page? simple, it can't.
That's the point...
> 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...
For XML parsing... I think I have a solution...
> Tonight, Federico opened my eyes (man, I'll miss that guy! these
> exoffice mean men are stealing all my friends, damn it! :)
Read the other reply :)
> 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.
You basically apply the transformation and THEN compile the resulting
XML... Did I get it right????
In that case, you have to specify how you can include code into the XML,
but I believe it's possible...
> QED :)
This brings me back to high school time ... Quod Erat Demostrandum...
> NOTE: I still like the ability to use XSP as a taglib for direct code
> inclusion inside a page, it may be helpful.
Yep...
> 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 :)
I still have to figure out HOW it's possible (from the implementation
point of view) but I believe it's possible...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Happy to be wrong!
Posted by Ted <te...@gs2admin1.e-meet.com>.
> At the end: XSP will remain. Period. Is that clear enough?
Yes.
> > Case 2:
> > > > which makes XSP totally useless since it's just a step between XSLT
> > > > transformations.
Perhaps:
...which makes XSP redundant since...
would have reduced the panic:)
Everything is clear, sir. Thank you!
Ted
Stefano Mazzocchi wrote:
>
> Ted wrote:
> >
> > Stefano,
> >
> > Take a look at this quotes I snipped from you! Of course you would
> > create a stir here, being the headmaster of this effort:
> >
> > Case 1:
> > > >1) XSP is going nowhere!!!
>
> I'm sorry... this was an english translation of my italian thoughts... I
> should have written (as Steve explained to me privately... thanks
> Steve!)
>
> 1) XSP is not going anywhere!!
>
> Latin languages are more rational: two negations end up with an
> assertion. In english, everything is so damn blurred :)
>
> > Case 2:
> > > > which makes XSP totally useless since it's just a step between XSLT
> > > > transformations.
> >
> > I think it was that way it was said rather than what was being said:)
>
> Ehy, if you decontextualize my words, you can make me say almost
> anything you want.... that's a journalist job :)
>
> At the end: XSP will remain. Period. Is that clear enough?
>
> Stefano.
Re: Happy to be wrong!
Posted by Stefano Mazzocchi <st...@apache.org>.
Ted wrote:
>
> Stefano,
>
> Take a look at this quotes I snipped from you! Of course you would
> create a stir here, being the headmaster of this effort:
>
> Case 1:
> > >1) XSP is going nowhere!!!
I'm sorry... this was an english translation of my italian thoughts... I
should have written (as Steve explained to me privately... thanks
Steve!)
1) XSP is not going anywhere!!
Latin languages are more rational: two negations end up with an
assertion. In english, everything is so damn blurred :)
> Case 2:
> > > which makes XSP totally useless since it's just a step between XSLT
> > > transformations.
>
> I think it was that way it was said rather than what was being said:)
Ehy, if you decontextualize my words, you can make me say almost
anything you want.... that's a journalist job :)
At the end: XSP will remain. Period. Is that clear enough?
Stefano.
Re: Happy to be wrong!
Posted by Ted <te...@gs2admin1.e-meet.com>.
Stefano,
Take a look at this quotes I snipped from you! Of course you would
create a stir here, being the headmaster of this effort:
Case 1:
> >1) XSP is going nowhere!!!
Case 2:
> > which makes XSP totally useless since it's just a step between XSLT
> > transformations.
I think it was that way it was said rather than what was being said:)
Ted
Chaos has bifurcated.
Re: Happy to be wrong!
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 28 Jan 2000, Stefano Mazzocchi wrote:
> 1) XSP is going nowhere!!! The whole thread is about implementation
> details and distribution of code and human resources to the Xalan/Cocoon
> project and some theorical reasonings that we had since may 99 (yes,
> guys, I'm slow, I know that!)
Your pardon, guys, I just discovered the root of my misunderstanding. You
say, 'XSP is going nowhere' or alternately 'XSP is not going anywhere',
meaning 'XSP is here to stay, we like XSP, we will keep using XSP'.
I read, 'XSP is going nowhere' or alternately 'XSP is not going anywhere',
and understand you to mean, 'XSP is a dead end, no one is using XSP, we're
not going to continue to improve and enhance XSP'. Therein lies much of
the confusion, I suspect.
- donald
Re: Happy to be wrong!
Posted by Mike Engelhart <me...@earthtrip.com>.
Stefano Mazzocchi wrote:
> So, if you planned/started to use XSP, go right ahead full steam: they
> have never been so solid as today.
Aye, aye captain...
:-)
Re: Happy to be wrong!
Posted by Stefano Mazzocchi <st...@apache.org>.
Mike Engelhart wrote:
>
> Stefano Mazzocchi wrote:
>
> > Have you ever been happy to be wrong?
> >
> Sorry to be so ignorant but where does that leave dynamic content
> generation? What is the link between code that does business logic, data
> access, etc. and the XML page you're trying to transform?
>
> Also as I've been thinking about moving my JSP to XSP, will XSP be supported
> well enough into the future that people can use XSP now because we have work
> to do and then move to E-XSLT when that is ready. It sounds like that is
> pretty long ways off in development terms.
NONONONONO... :)
Sorry, people, I should have sent that mail privately to the people
involved... it contains many details that were dealt with privately so I
will explain futher for those of you who didn't get a clue on what was
going on :)
1) XSP is going nowhere!!! The whole thread is about implementation
details and distribution of code and human resources to the Xalan/Cocoon
project and some theorical reasonings that we had since may 99 (yes,
guys, I'm slow, I know that!)
2) XSP is a namespace and a taglib. We _guarantee_ that we'll continue
to support it one way or the other... it will change _how_ their
execution/compilation is performed, but it will not change how the spec
is done and how your pages are executed.
3) point 1 and 2 are carved in stone! So it's point 3)
4) It might happen that XSP influence JSP-next to fix some of their XML
problems. If this happens, we'll provide a smoot XSP to JSP-next
transition with transformation sheets that allow you not to waste time
on porting you stuff over. READ CAREFULLY: it _might_ happen, or if this
doesn't happen we'll stay with XSP.
So, if you planned/started to use XSP, go right ahead full steam: they
have never been so solid as today.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: Happy to be wrong!
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Mike Engelhart wrote:
>
> Stefano Mazzocchi wrote:
>
> > Have you ever been happy to be wrong?
> >
> Sorry to be so ignorant but where does that leave dynamic content
> generation? What is the link between code that does business logic, data
> access, etc. and the XML page you're trying to transform?
If XSP is a taglib for E-XSLT, you will be able to include code into
your source documents... As you do with XSP today :)
> Also as I've been thinking about moving my JSP to XSP, will XSP be supported
> well enough into the future that people can use XSP now because we have work
> to do and then move to E-XSLT when that is ready. It sounds like that is
> pretty long ways off in development terms.
I am thinking if it's possible to convert current XSP into the future
E-XSLT code...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Happy to be wrong!
Posted by Mike Engelhart <me...@earthtrip.com>.
Stefano Mazzocchi wrote:
> Have you ever been happy to be wrong?
>
Sorry to be so ignorant but where does that leave dynamic content
generation? What is the link between code that does business logic, data
access, etc. and the XML page you're trying to transform?
Also as I've been thinking about moving my JSP to XSP, will XSP be supported
well enough into the future that people can use XSP now because we have work
to do and then move to E-XSLT when that is ready. It sounds like that is
pretty long ways off in development terms.
Mike