cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject RE: XSLT/XSP Unification?
Date Tue, 25 Jan 2000 18:06:52 GMT

Ricardo, my hat's off to you for this great note.

> 2) Use XSP!

It seems like a minimal change should be made for things like xsp: include
so that it uses xsl:include instead (for instance).  In other words,
without doing much change to the XSP codebase, could we modify the *syntax*
of the language so that it is E-XSLT compatible?  It seems to me this
change should be made sooner rather than later.  I don't care who processes
these tags; what worries me is the multiple syntaxes, and, even more of a
worry, slight differences in semantics.

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

I would extend this a little bit.  First, Xalan already uses a BSF-based
extension implementation.  What is needed is to combine the XSP and Xalan
extension mechanism into a single, good mechanism (some other XSLT
processor vendors may want to get into this also).  This mechanism can be
fed in to the W3C process to develop a truly standard mechanism.  To be
clear:  I am very unhappy with the current Xalan extension syntax;  it
sucks... there are too many ways to do things, it is confusing, and it is
not robust enough.  I would be *ecstatically* happy if the folks currently
working on XSP extensions would extend their reach to Xalan extensions.

> 4) Leverage XSP's code generation machinery for XSLT extension
development
>     by writing the appropriate _last-stage_ libraries for each scripting
> language.

+1

>     NOTE: Existing XSP libraries should remain unchanged as they're
> expressed
>     in terms of the current, already processor-independent XSP tagset

Any idea how hard it would be to get these to work with Xalan's extension
mechanism?  (I'll try and get a look at the code in the next couple of
days).

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

Yep, though I think we need to bound this, define it more, and develop some
target dates.  Are there folks who want to start a discussion about this,
and folks who want to take this under their wing?  I think this discussion
should probably occur on the Xalan list.

> 7) Last (but not least!) work hard to define a robust formalism to derive
>    schemata and dynamic tagsets from [UML] conceptual models.

Hmm... this seems to me to be, while a good idea, beyond what we should be
trying to achieve in this proposal.

There is a lot of talk in this thread about the models of "content
generation and [rule-based] content transformation".  Personally, this is
beyond the scope of my thinking.  I'm agnostic whether you generate content
directly from an XSLT stylesheet, as part of a three-step process, or as
part of an XSP process that also generates presentation-level markup (as in
Mike Williams's note).  XSLT is a language syntax... a low-level tool, that
is appropriate for a range of uses.  I just don't want to see multiple XML
syntaxes flying around that do the same thing at the primative level, and
hate to see the community fragmented in different but similar efforts, when
instead we could be pooling our resources on reuseable components.

-scott




                                                                                         
                         
                    "Ricardo                                                             
                         
                    Rocha"               To:     <cocoon-dev@xml.apache.org>       
                               
                    <ricardo@apac        cc:     <xalan-dev@xml.apache.org>, (bcc:
Scott Boag/CAM/Lotus)           
                    he.org>              Subject:     RE: XSLT/XSP Unification?       
                            
                                                                                         
                         
                    01/25/00                                                             
                         
                    07:13 AM                                                             
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         





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
things
> 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
positions
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
discussion
    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
implemented,
    XSP _code generation_ facilities should still play an enabling role in
its
    adoption

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,
overlap

- 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
transformations

- Both languages aim at supporting multiple scripting languages. In
particular,
  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
   constraints

- 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
stylesheets
  (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
by
           [interpreted] XSLT processing
    2.3) For those XSLT implementations not supporting extension elements
and
           functions

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

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

6) Develop stylesheet compilation to achieve killer performance for
languages
    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...

Ricardo






Mime
View raw message