cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Rocha" <>
Subject RE: XSLT/XSP Unification?
Date Tue, 25 Jan 2000 12:13:36 GMT

Scott Boag wrote:
> 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
> being unified within Cocoon...

Steve Muench wrote:
> 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
> and smoothly transition to <xsp:xxx> or <xyz:xxx> actions to handle
> additional "vocabularies" of functionality...

Stefano Mazzocchi wrote:
> . . . I see a need for XSP, although I don't have problems to combine
> efforts so that the same taglibs may be used for JSP, XSP and E-XSLT.

I intend to contribute to this discussion in the firm belief that both
are reconcilable and, indeed, complementary. At the end of this posting I'm
including a proposal to achieve integration so, please, bear with me as I
provide context by recapitulating what has been stated so far.

After careful consideration (and also intense soul-searching, :-)) I've come
to understand that:

1) Yes, the integration of XSP and XSLT extensions is indeed convenient and
    beneficial. As Scott pointed out, the game is still early and this
    is very timely

2) This integration can certainly proceed without rendering the existing XSP
    code base obsolete. XSP strongly encourages an authoring style in which
    documents containing dynamic XML are also amenable to "extended" XSLT
    processing with minimal or no changes

3) This integration does not render XSP redundant or irrelevant. Unlike XSP,
    XSL extensions are not yet fully defined and no working implementation
    exists. Even after a complete XSLT definition is published and
    XSP _code generation_ facilities should still play an enabling role in

Scott and Steve have emphasized the areas where XSP and XSLT *with
extensions* share common traits:

- Both are _transformation_ languages and, as such, share a number of common
  constructs like <xxx:element> or <xxx:attribute> which, admittedly,

- Both languages support (and encourage) the use of semantically-oriented
  vocabularies that simplify and enrich dynamic web authoring

- The "traditional" distinction between the 2 languages (namely, XSLT as
   rule-based and XSP as logic-based)  blurs as XSLT extension elements and
   functions provide a _standard_  way of defining logic-based

- Both languages aim at supporting multiple scripting languages. In
  Xalan and XSP intend to use BSF for this purpose

- Both languages follow a "2-pass" processing model where "data generation"
  precedes presentation/styling

- Both languages support mixing dynamic and static content in the same XML
  document either as embedded logic in XSP pages or as "templateless"
  literal result elements

Stefano, on the other hand, has pointed out the areas where the two
languages (and the two approaches) differ:

-  XSP emphasizes a clear separation between [logic-based] content
   generation and [rule-based] content transformation. While XSLT
   with extensions provides a way of performing both in the same context
   (namely, stylesheet processing) these two forms of content manipulation
   follow very different patterns and are subject to very different

- By translating dynamic tags _and_ static content into an executable form,
  XSP will typically achieve better performance than a comparable XSLT
  transformation. In the future, though, properly applying compiled
  (when they become available) may yield equivalent performance

To this, I'd personally add that XSP addresses an all-important area that
XSLT extensions don't (and, probably, shouldn't?) address: code generation

Unlike XSLT, XSP has roots in the "server pages" technology, where a
primordial driving force was simplifying logic-based markup generation.

Here, we must humbly acknowledge an ASP's early contribution: by
embedding logic into otherwise static content (by means of the now
infamous <% %> delimiters), dynamic markup generation was greatly
simplified. This approach has been leveraged by JSP and is wildly
popular among servleteers.

XSP goes one step beyond by treating such markup as well-formed
XML, rather than as boilerplate text. This is probably its most distinctive
trait when compared with other server page technologies.

As much as XSLT extensions haven't been completely and clearly
defined, potential developers haven't [yet] realized that a significant
portion (if not typically most) of their code will have to deal with markup
generation. Whether DOM or SAX, dynamic XML content generation is
characterized by the need to wrap data as markup.

XSP accounts for this in a way that is much more expressive and easier
to use than other approaches (e.g. JSP) Thus, for example, code and
markup can be freely interspersed and nested as needed.

What sets XSP apart, though, (and this is especially relevant for XSLT
extension authoring) is its _layered_ approach to code generation,
based on tag libraries.

Tag libraries (themselves XSLT stylesheets, :-)) define the mapping
between dynamic tags and actual code in a language-independent way.
Such mappings are applied in succession, so that higher-level tag
vocabularies are typically expressed in terms of lower-level ones,
thus encouraging reuse.

This is an area where I feel strongly that XSLT extensions will
benefit most from XSP-related technology: instead of writing complex,
monolithic extension element/function handlers, developers can
use libraries to easily write markup-generation code focusing on
the "real" requirements of data manipulation.

Note that this applies even for (I'd say complementarily with) automated
XML-to-bean facilities like those preconized by the Java Binding proposal
(e.g. Exolab's Castor)

[I deeply thank the reader for his patience if he's made it to this point,

My proposal:

1) Encourage/Institute the strict use of dynamic tags (as opposed to
   embedded logic) in XSP pages to ensure they can be applied either
   XSP or XSLT extension processing when the latter becomes available

2) Use XSP!
    2.1) For applications requiring dynamic capabilities here and now
    2.2) For applications demanding high performance levels not attainable
           [interpreted] XSLT processing
    2.3) For those XSLT implementations not supporting extension elements

3) Develop a language-independent, BSF-based XSLT extension implementation
    for Xalan (I know this is obvious, :-) I'm including it here for

4) Leverage XSP's code generation machinery for XSLT extension development
    by writing the appropriate _last-stage_ libraries for each scripting
    NOTE: Existing XSP libraries should remain unchanged as they're
    in terms of the current, already processor-independent XSP tagset

6) Develop stylesheet compilation to achieve killer performance for
    that generate Java bytecodes (Java, NetRexx, Rhino Javascript, etc)

7) Last (but not least!) work hard to define a robust formalism to derive
    schemata and dynamic tagsets from [UML] conceptual models. Such
    formalism should provide the basis for designing dynamic, XML-based
    web applications. Eventually, this formalism could also provide the
    framework for a case-like tool/repository aimed at supporting XML
    web application development

My (admittedly verbose) 2 cents...


View raw message