cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Muench" <>
Subject Re: XSLT/XSP Unification?
Date Mon, 24 Jan 2000 20:19:08 GMT

I share your confusion and have been dropping
hints on the cocoon list off and on about
how these could come together. I'm hoping
it's just timing that's made the two stay
apart. Reading through the XSP docs and
finding tags like:


that mimic the <xsl:XXX> equivalents
made me wonder even more why these mechanisms
don't just find a happy marriage: XSP as a library
of extension elements. I know not every XSLT
processor has yet implemented extension elements
yet, so perhaps this was a consideration given
the timeframe.

The biggest concern I've heard from implementors
as I promote this idea is "but then we'd
have to run *twice* through the XSLProcessor
to process a page: once to produce the "data"
and once to "style it". And my answer is, "So?"
The benefits of having a built-in include
mechanism, and a set of core "actions" that
increasingly XML-savvy web developers are
becoming familiar with is compelling.

My gut feeling tells me that a unification
would deliver the benefits of both,
allowing people to use the core XSL actions for
the most basic things and smoothly transition
to <xsp:xxx> or <xyz:xxx> actions to handle
additional "vocabularies" of functionality
without having to wonder whether <xyz:element>
was the same thing as <xsl:element>.

While JSP is not generally talked about much
on this list, the JSP Tag Library mechanism
in JSP 1.1 seems to be trying to accomplish
the same kind of *core* + extension libs
idea around the JSP technology stack. XSLT Extension
elements seem like the natural XSL-way to do
the same thing.

Just my humble opinion...

Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
----- Original Message -----
From: "Scott Boag/CAM/Lotus" <>
To: <>
Cc: <>
Sent: Monday, January 24, 2000 10:56 AM
Subject: XSLT/XSP Unification?

| Well, I hope I don't ruffle any feathers with this one, or start a flame
| war.  This is an attempt to explore the possibilities of XSLT and XSP
| unified within Cocoon.  I'm probably off the mark a little bit here... I
| don't totally understand the XSP model, and haven't had time to go into it
| as deeply as I should.  But I wanted to get my thoughts out while the game
| is still early.  I suspect there have already been some conversations
| these lines that missed me or that I was not privy to.
| First, looking at XSP, it appears on one level to be doing something very
| similar to XSLT.  On another level, it appears to be doing stuff that
| improve the use of XSLT in batch environments.
| My assertions are:
| 1) The two technologies seem to unnecessarily  overlap.  This cause
| unneeded complexity and learning curve, and a burden for users who have to
| understand subtle differences between xsp:pi, xsp:include, namespace
| handling, whitespace handling, extensions, etc., and the XSLT
| 2) The two technologies ought to be combined: xsp as a namespace of the
| xslt transform.  Given "Literal Result Element as Stylesheet", I don't
| think you would loose anything in terms of simplicity.  XSP would be made
| stronger by use of XSLT features, and XSLT would be made stronger by use
| XSP features (I'm thinking primarily of using xsp:logic, xsp:expr, etc. as
| an extension mechanism within Xalan).
| 3) I need help on Xalan: the kind of resources that are being used in XSP.
| For instance, we badly need to build and refine the extension
| I note that XSP docs say they are thinking of using BSF, which Xalan
| already does.  The XSP "Util classes" are mostly perfectly appropriate for
| use in XSLT extensions.  It would be nice to work towards compiled
| stylesheet architecture, which is related to the work that is being done
| XSP (I think) etc. etc. etc.
| Note that the possibility exists here to work on a standard extension
| architecture that can be rolled back into the W3C.
| 4) I need to understand better XSP vs. XML-syntax for JSP... but, in any
| case, what a confusing picture...  JSP is justified because it is a stream
| model with generic data input... for certain types of jobs, JSP syntax is
| better choice.  On the other hand, while the same can be said of XSP, it
| seems to be an extra shade in between JSP and XSLT.
| 5) There is also the subject of the SQL processor, which is heavily
| to all this.  I would love to see the SQL stuff being set for XSP, be
| available for use in XSLT.
| 6) I don't think performance is an issue here.  A XSLT/XSP combo can
| perform just as well as raw XSP, and maybe better, given more focus.
| 7) I understand the need for simplicity in XSP.  But, I think if we worked
| closely together, we could come up with something close to being as
| that is a far more powerful sum of the parts.
| Comments?  If I'm way off mark, I'll just go sulk back to my cave...
| -scott

View raw message