tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <pele...@eng.sun.com>
Subject XML & JSP...
Date Tue, 04 Jan 2000 00:07:31 GMT
This is a long discussion and it is hard to carry through email
fragments.  I'll try but please give me some slack when interpreting
the mail.  I am going to use a number of excerpts to reply to.

Danno says...

> At the risk of getting into another "what the spec says" squabble, my
> reading indicates to me that the XML and the "jsp page" forms are two
> representations of the same data, and that they are not, under the current
> revision, ment to intermingle but to remain explicitly spereate.

I already sent mail on this.  Yes, Danno is correct, the intention of
the JSP 1.0 final and JSP 1.1 specs is for those two representations
not to be intermixed.

Stefano says...

| <applause>clap, clap, clap</applause>
| 
| Danno, thank you for introducing this. This will show Sun people, I'm
| not the only fool that ...

I have consistently said, in private and in public, that the cocoon
and xsp efforts have very valuable contributions that I hope can
be used in future JSP & Servlet efforts.

| ... thinks that the XML syntax for JSP is a _total_
| mistake.

I didn't read that in Danno's message.  Also see below...


| It was my very first comment to Eduardo about the JSP spec: XML support
| is fake. Totally. The idea is to "place XML stuff to show we care" so
| that PR people have something to say when the "what are you doing about
| XML" question comes up from the press.

I wrote the spec and I can say, with 100% confidence, that this was
not put there just to "show we care".

| Anil wrote ...
|
| > At some point we have also talked about transforming a JSP page into an
| > XML-compliant page. If such a transformation is defined then we could
| > just use the existing JSP parser to do that transformation and then
| > plug the code generator as a SAX backend. So the data flow would look
| > like:
| >
| > JSP page --> JSP2XML transform --> XML-parser --> JSP Listener -- generates
| >--> servlet.
| >
| > or
| >
| > XML-compliant JSP page --> XML-parser --> JSP Listener -- generates -->
| > servlet
| 
| <Ruby says...>
| I have access to an IBM implementation which follows the rough outline
| described above.  I would be quite willing to scavenging it and
| contributing the useful parts to Jakarta.  It contains a compile time
| custom tag mechanism with transformations either in Java or XSLT.

That was indeed the direction that we wanted to follow when we were
writing the JSP 1.0 spec in Apr/Mar (I may be off in the exact date)
'99.

I am not convinced this direction is intrinsically flawed. The
intention was to nail this down for JSP 1.1 but we ran out of time to
get things really right, and I felt we needed to understand better all
the issues.  That is an intrinsic burden with specs: once something is
in the spec it should be supported in future specs, (I know that has
not been necessarily the case for some of our specs, but that is the
goal), so we cannot just "try something out".


As we move into JSP.next, one of the first things is to spell out this
direction and understand really well all the issues.  It is my hope
that we can build on top of the experience with XSP and cocoon to do
this.

Stefano says...
 
| Also, the whole Servlet platform is _not_ ready to stand the XML
| challenges: how do I XSL-transform the output of my servlet? with
| servlet chaining? having to serialize and reparse the XML stuff every
| time? no way.

Agreed.  Some notion of Servlet composition / filtering seems needed.
I hope we can include something like that as part of Servlet.next, but
we have to talk with all parties about it.

| there is a big point where Sun folks and I disagree
| strongly: the need to extend JSP rather than create a new language.

I personally believe that it is possible to take the basic JSP
structure and build on it a language that is at least as capable as
XSP for handling XML.  It may be possible to write a purer version if
one where to drop backward compatibility concerns, but I (personally,
again) believe there is no significant benefit in doing so.

===================

Exactly what happens with JSP.next will depend on discussions within
the expert group.  If you want to influence that outcome, join the
expert group.  As I said in my previous message, the exact shape of
the process is still to be determined.

Two important points to take into account are:

- backward compatibility is very important to many people, specially
  in the enterprise.
- we have created a good mindshare with JSP that we can exploit.

===================


I should follow-up with additional technical documents describing
alternatives, etc, but at this moment I only have things I wrote a
few months ago.  I'll see what I can do in the near future.  


Hope this helps,

	- eduard/o

Mime
View raw message