Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 27592 invoked from network); 25 Jan 2000 18:08:39 -0000 Received: from lotus2.lotus.com (192.233.136.8) by 63.211.145.10 with SMTP; 25 Jan 2000 18:08:39 -0000 Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA18345; Tue, 25 Jan 2000 13:23:30 -0500 (EST) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA22339; Tue, 25 Jan 2000 13:08:10 -0500 (EST) Subject: RE: XSLT/XSP Unification? To: cocoon-dev@xml.apache.org Cc: xalan-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0 March 30, 1999 From: "Scott Boag/CAM/Lotus" Date: Tue, 25 Jan 2000 13:06:52 -0500 Message-ID: X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V503_01122000 |January 12, 2000) at 01/25/2000 01:09:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: , (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 or 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 or 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