From shelley94@example.net Fri Mar 2 20:37:03 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 6966 invoked from network); 2 Mar 2001 20:37:03 -0000 Received: from unknown (HELO uniweb.net.co) (83.161.120.155) by h31.sny.collab.net with SMTP; 2 Mar 2001 20:37:03 -0000 Received: from apache.org ([83.161.120.155]) by uniweb.net.co ; Fri, 02 Mar 2001 15:35:01 -500 GMT Sender: ricardo Message-ID: <shelley94@example.net> Date: Fri, 02 Mar 2001 15:49:40 +0100 From: Ricardo Rocha <shelley94@example.net> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Cocoon Developers <shelley94@example.net>, XSPDev <shelley94@example.net> Subject: [RT] Rationalizing XSP (was: XSP and aspects) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi guys, In response to the enlightening "XSP and aspects" thread posted by Allan Erskine and Stefano Mazzocchi, I'd like to summarize and comment on the various issues and goals discussed: - Capturing aspects in XSP - Making XSP a general-purpose factory for server components (other than server pages) - Refactoring XSP implementation to avoid "the same but different" syndrome visible in the redundant implementation of server pages and the compiled sitemap - Avoiding "language impedance" by placing only pure markup in XSP pages with no recurse to the underlying programming language - Defining a logicsheet language: SiLLy I apologize if the ideas presented here look too implementation-oriented, Cocoon-biased or Java-biased. Despite this, I feel most of the concepts discussed are applicable to XSP at large (and, therefore, may be also applicable to AxKit's Perl XSP) 1) Capturing aspects in XSP In Allan's words, capturing aspects in XSP boils down to choosing markup to represent and encapsulate what would otherwise be a crosscutting feature. To begin, XSP is generally seen as a (source) code-generation markup language. NB: Implementation-wise, though, it could be an _object composition_ language instead, with no need to resort to code generation except, perhaps, for supercompilation-like optimizations. (I'd like to elaborate on this later, on a separate post: a composition-oriented approach to dynamic XML generation based on Avalon patterns.) AspectJ (our reference for AOP) acts as a Java preprocessor thus also "incurring" in code generation. Aspects observe and react to object events such as method invocations or exception handling. AspectJ achieves this by inserting aspect-support code at appropriate spots (join points) so that the crosscutting feature is accounted for in a transparent and uniform fashion across different classes. OT: With the introduction of dynamic proxies in Java 1.3, preprocessing is no longer the only obvious option: it's now possible to trap method invocations and exception throwing using dynamic proxies. XSP code generation can be easily used for the same purpose although, as Stefano points out, XML syntax is very unfriendly with code (the "language impedance" issue commented below) Consider XSP page debugging: the XSP code generator could well adorn generated code to keep track of source lines in the XSP page and all intervening logicsheets. Thus, when an exception is thrown, this information would be used to dynamically generate an error page displaying the appropriate context for the generated source program, the original XSP page and all relevant logicsheets: an XSP developer's nirvana! :-) In fact, this wouldn't need to be the code generator's responsibility: an otherwise "regular" logicsheet could be applied that scans all <xsp:expr> and <xsp:logic> tags in order to append location info to the generated source program. All in an aspect-oriented fashion. Of course, there are many more implications to making XSP aspect-aware, but one could say that the basic mechanisms needed to achieve are already in place. If we refine the logicsheet applying mechanism and (ideally) also disallow embedding raw code in XSP pages (i.e., we base all dynamic XML generation on logicsheets) then capturing/representing aspects would become much simpler. (This is even more obvious under the composition model mentioned above.) 2) Making XSP a general-purpose factory for server components Probably the most wasteful single mistake in the existing (Cocoon) XSP implementations is limiting code generation to Producers (C1) and Generators (C2). This undesirable "feature" stems from the fact that the last-stage logicsheet applied (the one dealing with the XSP tagset as such) also contains the compilation unit skeleton. If we decouple XSP from the target source program type and the invocation environment (e.g. http/servlet) then the XSP language could be used for building practically any kind of markup-generating program. To achieve this, we'd simply need to follow an order like the following in the XSP code generation pipeline: a) Apply aspect-oriented logicsheets. This step will surround (aspect-oriented) dynamic tags with appropriate aspect-support logic (in the target programming language). b) Apply dynamic tag substitution (non-aspect) logicsheets. This step will translate dynamic tags to their corresponding <xsp:logic> and <xsp:expr> equivalents for the target programming language. c) Apply the compilation unit skeleton logicsheet. This step will build a specific program type (Generator, Transformer, other). It's here where we'd decouple XSP from its current server pages single-mindedness d) Apply environment-specific logicsheet(s). This steps results in the inclusion of declarations that make the calling environment's object model readily available to the generated program e) Apply the last stage XSP tagset logicsheet. This step will produce the final source program. This sketchy pipeline pattern can be extended to support different XML API's (e.g. SAX, DOM, JDOM) It's also based on the assumption that a single target programming language is used. Btw, Sam Ruby has long advocated the convenience of allowing for multiple programming language support, a feature already present in Websphere's JSP implementation. Note that this would allow for the reuse of logicsheets (actually, taglibs) written in different languages in the same XSP document. I'm still working on exploring different alternatives, but it seems that the factors [aspects? :-)] involved here are: - Program type (compilation unit skeleton: Generator, Transformer, etc.) - Programming language(s) (Java, Javascript, NetRexx, etc) - Invocation environment (http/servlet, command-line) - XML API's (SAX, DOM, JDOM) - Taglibs/logicsheets - Aspects 3) Refactoring the XSP implementation to avoid redundance Currently, there are 2 overlapping, redundant "markup languages" in Cocoon2: XSP for server pages and XSP for the sitemap. Allan Erskine also mentions a possible "flowmap" which (in the current setup) would require the creation of a third MarkupLanguage implementation. Historically, the MarkupLanguage abstraction was meant to signify different code generation tagsets, namely: XSP (<xsp:logic>, <xsp:expr>) and JSP (<jsp:scriptlet>, <jsp:expr>). Admittedly, even for this case it was unnecessary: it would be much simpler to translate JSP code generation tags into their XSP counterparts without the need to introduce the notion of a code-generation markup language (SOM!) When the need for sitemap compilation was perceived and its implementation pursued, "MarkupLanguage" was understood as what I've called above the "program unit skeleton" so a new MarkupLanguage (pirated from the server pages XSP implementation) was created: SitemapMarkupLanguage. In fact, this was the only possible workaround that allowed the existing XSP code generation framework to be reused. Should I have timely decoupled the code generation engine from the target program type, we wouldn't have a separate sitemap MarkupLanguage today. Again:SOM! :-( Fortunately, the solution is obvious: deprecating MarkupLanguage and adding a separate program skeleton logicsheet step in the XSP code generation pipeline. This way, both the sitemap and server pages can reuse the code generation machinery without redundance. This is also true for "new" program types such as Transformers and, yes, Allan's flowmap. 4) Avoiding "language impedance" in XSP This is a tough one: server pages developers seem to love the ability to embed "raw" source code in markup, a trend originally set by M$'s ASP and later embraced by JSP and XSP. While this has the appeal of enabling quick prototyping, we have come to suspect that _any_ language-specific programming constructs in XSP break encapsulation and are, therefore, WRONG! Embedding code in markup not only breaks encapsulation: it hinders reuse! Language impedance shows up in other ways as well. Probably the ugliest one is the need to escape markup metacharacters (&, <, >) or the alternative enclosing of source code in CDATA sections. Both XSP and JSP provide a way to encapsulate the abovementioned programming constructs: taglibs (logicsheets.) Taglibs (and their implementing logicsheets) are much more than a nice way to allow non-programmers to write dynamic server pages: they are _the_ proper way to express dynamic (i.e., logic-based) content generation in XML. Associating taglibs with namespaces, for instance, supports very powerful constructs: multi-dimensionality, aspect orientation... This whole point seems to boil down to the following: All that can be achieved by embedding code in markup can also be achieved by inlining the invocation of a suitably defined method on a suitably defined object. As it turns out, such "suitably defined object" doesn't need to be a markup-aware wrapper around an application object or component. There are many ways to transparently convert regular objects to markup (e.g., using introspection in Java, a la Castor). In cases in which a more "specialized" markup version of the object is required, extending a regular class to implement XMLFragment might suffice. In other cases in which arguments to a "suitably defined method" are themselves markup, an object representation of such markup (like bytecode compiled xml) is appropriate. Note that this scenario typically coincides with the case in which one needs to do selection or iteration over markup. This should make it unnecessary to come up with procedural constructs such as "<xsp:if>" or "<xsp:for-each>" that are proposed from time to time. All that said, embedded code can always be replaced by method invocations on _components_. Correspondingly, it is always possible to associate (logicsheet) namespaces with component instance declarations so that dynamic tags are mapped to method calls on such components. (These concepts are closely related to the composition-oriented approach based on Avalon patterns and mentioned above.) Last, but not least, pretty much as embedding code in XSP pages is unnecessary (and undesirable), it's also true that: generating free-from code in logicsheets is also unnecessary (and undesiderable). I think that logicsheets should limit themselves to generate method calls on component instances. I have the impression that logicsheets should/need _not_ generate arbitrary statements, much less generate inner classes or the like. Why? First: it's not necessary; anything that can be achieved by building a class from a template can be achieved by properly configuring an existing generic component. Second: for the same reasons that apply to embedding code in XSP pages, anything that can be achieved by generating multiple statements can be achieved by a method call. Advantages: - Code size is dramatically decreased - Logicsheet complexity is dramatically decreased - No conflict with variable names previously defined by the same or other logicsheets In conclusion, avoiding the code/markup impedance can be achieved by: - Outlawing embedding code in markup in XSP pages - Basing code generation (i.e., logicsheets) on emitting code that simply interacts with well-defined components 5) Defining a logicsheet language: SiLLy NB: Logichseets are far simpler in AxKit (Perl). Boy, are they lucky! XSLT-based XSP logichseet authoring has turned out to be a true PITA (tm). XSLT is _incredibly_ powerful, despite the claims of those who only seem to understand procedural transformations (cousins of the ones advocating the infamous <xsl:script> tag which, btw, I've seen only in M$'s implementation) OT: There has been a controversy about XSP vs XSLT extensions. The new controversy about XSLT vs XQuery promises to be enlightening in this regard: while nobody wants redundancy, I also wonder whether there's a "one size fits all" attitude. A juicy subject, indeed, but that deserves a separate discussion... Powerful as XSLT is, its use in code-generation logicsheets doesn't come without problems. Granted, most transformational patterns characteristic of code generation can be correctly and completely expressed in XSLT without resorting to extension functions (wich, btw, are currently available only in Xalan). Their implementation, though, is usually too verbose and convoluted. To illustrate the point, remember how one must declare dynamic tag parameters so that they can be referenced as XSLT variables in source code templates: tedious, repetitive, error-prone. String manipulation is also a problem area. Think of the complexity seen in the "get-nested-string" utility template. Indentation in generated code is also a problem. While, for most languages, this is just an aesthetic consideration, there are other cases in which it can become a real problem: think of [J]Python. A higher level language is called for and we all have known it for a while now. That's what SiLLy is about. The simplest alternative is for SiLLy to be preprocessed to XSLT: that way we simplify logicsheet authoring while preserving the power and portability of XSLT. In order to transform SiLLY into XSLT, an XSLT stylesheet can be used. Using XSLT to generate XSLT is a possibility contemplated in the XSLT spec itself. This approach has been addressed before (admittedly in a very superficial way.) If we restricted XSP code generation to component declarations and method invocations, SiLLy could become much simplified: <logicsheet ns-uri="http://plenix.org/xsp/date-format" interface="org.plenix.sll.DateFormatter"> <implementation ns-prefix="date-format" class="org.plenix.sll.DefaultDateFormatter"/> <tag name="format" method="doFormat"> <arg name="date" type="java.util.Date"/> <arg name="mask" type="java.lang.String" default="hh:mm:ss"/> </tag> </logicsheet> <logicsheet ns-uri="http://plenix.org/xsp/system" interface="org.plenix.sll.SystemInfo"> <implementation ns-prefix="system" class="org.plenix.sll.DefaultSystemInfo"/> <tag name="current-time" method="getCurrentTime"/> </logicsheet> <page> <p xmlns:system="http://org.plenix/xsp/system" xmlns:date-format="http://org.plenix/xsp/date-format"> Hi there! To the best of my knowledge, it's now <date-format:format mask="hh:mm"> <date-format:date><system:current-time/></date-format:date> </date-format:format> </p> </page> To be honest, the above example is a simplification of the syntax I'm testing for the composition-based approach I've been mentioning. This approach does not require code generation: it uses the same Avalon component managemenet patterns Cocoon2 itself is based on. Anyway, a special-purpose, "manual" transformer (in the Trax sense) may be appropriate if we base everything on components/methods: XSLT may no longer be the best choice for processing logicsheets. Un saludo tropical desde la Tierra del Olvido! Ricardo From shelley94@example.net Mon Mar 5 07:27:10 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 1448 invoked from network); 5 Mar 2001 07:27:10 -0000 Received: from mail.ursus.ru (HELO ursus.ru) (83.161.120.155) by h31.sny.collab.net with SMTP; 5 Mar 2001 07:27:10 -0000 Received: from [83.161.120.155] (HELO anthony) by ursus.ru (Stalker SMTP Server 1.7) with SMTP id S.0000276184 for <shelley94@example.net>; Mon, 05 Mar 2001 10:25:14 +0400 From: "Tagunov Anthony" <shelley94@example.net> To: "shelley94@example.net" <shelley94@example.net> Date: Mon, 05 Mar 2001 10:29:50 +0300 Reply-To: "Tagunov Anthony" <shelley94@example.net> Priority: Normal X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT (4.0.1381;6) In-Reply-To: <shelley94@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Subject: Re: [RT] Rationalizing XSP (was: XSP and aspects) Message-Id: <shelley94@example.net> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 02 Mar 2001 15:49:40 +0100, Ricardo Rocha wrote: > >In other cases in which arguments to a "suitably defined method" are >themselves markup, an object representation of such markup (like >bytecode >compiled xml) is appropriate. Please excuse my boldness, but won't this decrease performance? Serialization, deserialization.. Maybe it should still be a stream of SAX event? <disclaimer> I'm a novice, don't take it too serious, just speculating</disclaimer> Best regards, Tagunov Anthony From shelley94@example.net Mon Mar 5 10:02:44 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 20298 invoked from network); 5 Mar 2001 10:02:44 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 10:02:44 -0000 Received: (qmail 24428 invoked from network); 5 Mar 2001 10:02:53 -0000 Received: from softdnserror (HELO ?83.161.120.155?) (83.161.120.155) by mailgate.sergeant.org with SMTP; 5 Mar 2001 10:02:53 -0000 Date: Mon, 5 Mar 2001 09:58:37 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Ricardo Rocha <shelley94@example.net> cc: XSPDev <shelley94@example.net> Subject: XSP and Aspects (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <shelley94@example.net> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Note: I'm keeping these replies off cocoon-dev. I see no reason to CC there - you're not CC'ing axkit-devel too. I'm going to try and reply to each one of these separately. On Fri, 2 Mar 2001, Ricardo Rocha wrote: > 1) Capturing aspects in XSP > > In Allan's words, capturing aspects in XSP boils down to choosing markup > to represent and encapsulate what would otherwise be a crosscutting > feature. > > To begin, XSP is generally seen as a (source) code-generation markup > language. > > NB: Implementation-wise, though, it could be an _object composition_ > language instead, with no need to resort to code generation > except, perhaps, for supercompilation-like optimizations. (I'd > like to elaborate on this later, on a separate post: a > composition-oriented approach to dynamic XML generation based on > Avalon patterns.) > > AspectJ (our reference for AOP) acts as a Java preprocessor thus also > "incurring" in code generation. > > Aspects observe and react to object events such as method invocations or > exception handling. AspectJ achieves this by inserting aspect-support > code at appropriate spots (join points) so that the crosscutting feature > is accounted for in a transparent and uniform fashion across different > classes. > > OT: With the introduction of dynamic proxies in Java 1.3, > preprocessing > is no longer the only obvious option: it's now possible to trap > method invocations and exception throwing using dynamic proxies. > > XSP code generation can be easily used for the same purpose although, as > Stefano points out, XML syntax is very unfriendly with code (the > "language impedance" issue commented below) > > Consider XSP page debugging: the XSP code generator could well adorn > generated code to keep track of source lines in the XSP page and all > intervening logicsheets. Thus, when an exception is thrown, this > information would be used to dynamically generate an error page > displaying the appropriate context for the generated source program, > the original XSP page and all relevant logicsheets: an XSP developer's > nirvana! :-) > > In fact, this wouldn't need to be the code generator's responsibility: > an otherwise "regular" logicsheet could be applied that scans all > <xsp:expr> and <xsp:logic> tags in order to append location info to the > generated source program. All in an aspect-oriented fashion. > > Of course, there are many more implications to making XSP aspect-aware, > but one could say that the basic mechanisms needed to achieve are > already in place. > > If we refine the logicsheet applying mechanism and (ideally) also > disallow embedding raw code in XSP pages (i.e., we base all dynamic XML > generation on logicsheets) then capturing/representing aspects would > become much simpler. (This is even more obvious under the composition > model mentioned above.) What I'm hearing is that aspects are something that someone invented because of the weakness of Java's dynamism. In Perl inserting a proxy object to catch method calls and such is pretty trivial, so we don't name it, that's just "programming perl" :-) Having said that, I don't think you've really identified a problem with XSP, so I'm not sure what this would gain us. It seems like somebody's pontification turned into an RT, without any real purpose. I'll come onto removing raw code in XSP in one of the other sections where it's more relevant. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ From shelley94@example.net Mon Mar 5 10:16:29 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 32568 invoked from network); 5 Mar 2001 10:16:29 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 10:16:29 -0000 Received: (qmail 24591 invoked from network); 5 Mar 2001 10:16:39 -0000 Received: from unknown (HELO ?83.161.120.155?) (83.161.120.155) by mailgate.sergeant.org with SMTP; 5 Mar 2001 10:16:39 -0000 Date: Mon, 5 Mar 2001 10:12:49 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Ricardo Rocha <shelley94@example.net> cc: XSPDev <shelley94@example.net> Subject: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <shelley94@example.net> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Again, keeping this off cocoon-dev. On Fri, 2 Mar 2001, Ricardo Rocha wrote: > 2) Making XSP a general-purpose factory for server components > > Probably the most wasteful single mistake in the existing (Cocoon) XSP > implementations is limiting code generation to Producers (C1) and > Generators (C2). > > This undesirable "feature" stems from the fact that the last-stage > logicsheet applied (the one dealing with the XSP tagset as such) also > contains the compilation unit skeleton. > > If we decouple XSP from the target source program type and the > invocation environment (e.g. http/servlet) then the XSP language could > be used for building practically any kind of markup-generating program. I've snipped the rest because it's all cocoon-isms. All I can say to this is that under AxKit, it is already possible to use XSP to generate XML anywhere, provided you can extract the generated code (we don't save to a file like Cocoon does). The code is just a simple handler function that gets invoked at execution time. The only time it becomes uncallable from outside of AxKit is if it makes use of the $cgi or $r objects. Plus AxKit has no concept of Generators and whatnot. That's all YAGTNI to us. XSP is just another callable engine in the pipeline. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ From shelley94@example.net Mon Mar 5 10:19:09 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 34200 invoked from network); 5 Mar 2001 10:19:09 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 10:19:09 -0000 Received: (qmail 24650 invoked from network); 5 Mar 2001 10:19:19 -0000 Received: from unknown (HELO ?83.161.120.155?) (83.161.120.155) by mailgate.sergeant.org with SMTP; 5 Mar 2001 10:19:19 -0000 Date: Mon, 5 Mar 2001 10:16:18 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Ricardo Rocha <shelley94@example.net> cc: XSPDev <shelley94@example.net> Subject: Re-using XSP internally in Cocoon (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <shelley94@example.net> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 2 Mar 2001, Ricardo Rocha wrote: > 3) Refactoring the XSP implementation to avoid redundance > > Currently, there are 2 overlapping, redundant "markup languages" in > Cocoon2: XSP for server pages and XSP for the sitemap. Allan Erskine > also mentions a possible "flowmap" which (in the current setup) would > require the creation of a third MarkupLanguage implementation. > > Historically, the MarkupLanguage abstraction was meant to signify > different code generation tagsets, namely: XSP (<xsp:logic>, <xsp:expr>) > and JSP (<jsp:scriptlet>, <jsp:expr>). Admittedly, even for this case it > was unnecessary: it would be much simpler to translate JSP code > generation tags into their XSP counterparts without the need to > introduce the notion of a code-generation markup language (SOM!) > > When the need for sitemap compilation was perceived and its > implementation pursued, "MarkupLanguage" was understood as what I've > called above the "program unit skeleton" so a new MarkupLanguage > (pirated from the server pages XSP implementation) was created: > SitemapMarkupLanguage. > > In fact, this was the only possible workaround that allowed the existing > XSP code generation framework to be reused. > > Should I have timely decoupled the code generation engine from the > target program type, we wouldn't have a separate sitemap MarkupLanguage > today. Again:SOM! :-( > > Fortunately, the solution is obvious: deprecating MarkupLanguage and > adding a separate program skeleton logicsheet step in the XSP code > generation pipeline. > > This way, both the sitemap and server pages can reuse the code > generation machinery without redundance. > > This is also true for "new" program types such as Transformers and, yes, > Allan's flowmap. This is a cocoon issue and should probably not have been included in this RT to xsp-dev. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ From shelley94@example.net Mon Mar 5 10:29:17 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 43693 invoked from network); 5 Mar 2001 10:29:17 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 10:29:17 -0000 Received: (qmail 24806 invoked from network); 5 Mar 2001 10:29:23 -0000 Received: from unknown (HELO ?83.161.120.155?) (83.161.120.155) by mailgate.sergeant.org with SMTP; 5 Mar 2001 10:29:23 -0000 Date: Mon, 5 Mar 2001 10:26:22 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Ricardo Rocha <shelley94@example.net> cc: XSPDev <shelley94@example.net> Subject: Avoiding "language impedance" in XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <shelley94@example.net> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 2 Mar 2001, Ricardo Rocha wrote: > 4) Avoiding "language impedance" in XSP > > This is a tough one: server pages developers seem to love the ability to > embed "raw" source code in markup, a trend originally set by M$'s ASP > and later embraced by JSP and XSP. > > While this has the appeal of enabling quick prototyping, we have come > to suspect that _any_ language-specific programming constructs in XSP > break encapsulation and are, therefore, WRONG! > > Embedding code in markup not only breaks encapsulation: it hinders > reuse! I think you're wrong here. Way off base. While I understand you're talking about this from a theoretical standpoint, you cannot ignore the practical issues. People can cope with <foo:do_something_major/>, but they don't like doing <xsp:if> or whatever the equivalent would be. There's just so much that a programming language can do, and a taglib can't. Side effects being the one major thing that springs to mind. In short, I think you're focussing on it incorrectly: The re-usable component is the generated XML - not tiny parts of the XSP page that you might be writing to build that XML. And putting code in XSP doesn't kill that notion in any way shape or form. Taglibs are great, but they are never going to be trivial to implement, and that is *A GOOD THING*. Its like the difference between classes and code that uses those classes. Writing the classes is harder than writing the code that uses the classes, and so it should be done with a clear design and requirements document. Writing the code that uses those classes needn't be that way. > This whole point seems to boil down to the following: > > All that can be achieved by embedding code in markup can also be > achieved by inlining the invocation of a suitably defined method > on a suitably defined object. Just because you can, doesn't mean that you should. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ From shelley94@example.net Mon Mar 5 10:40:39 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 51085 invoked from network); 5 Mar 2001 10:40:39 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 10:40:39 -0000 Received: (qmail 24986 invoked from network); 5 Mar 2001 10:40:49 -0000 Received: from unknown (HELO ?83.161.120.155?) (83.161.120.155) by mailgate.sergeant.org with SMTP; 5 Mar 2001 10:40:49 -0000 Date: Mon, 5 Mar 2001 10:37:48 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Ricardo Rocha <shelley94@example.net> cc: XSPDev <shelley94@example.net> Subject: SiLLy (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <shelley94@example.net> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 2 Mar 2001, Ricardo Rocha wrote: > 5) Defining a logicsheet language: SiLLy > > NB: Logichseets are far simpler in AxKit (Perl). Boy, are they lucky! Yup :-) Actually someone has also submitted a taglib module that allows you to just write a Perl class, and all its methods are turned into taglibs. That will probably be included in the next release of AxKit. > XSLT-based XSP logichseet authoring has turned out to be a true PITA > (tm). Well I actually don't claim that SAX based code generation is much easier - its more that Perl code is shorter generally, so it looks easier. But SAX presents its own set of problems that we have to deal with. > XSLT is _incredibly_ powerful, despite the claims of those who only seem > to understand procedural transformations (cousins of the ones advocating > the infamous <xsl:script> tag which, btw, I've seen only in M$'s > implementation) > > OT: There has been a controversy about XSP vs XSLT extensions. The new > controversy about XSLT vs XQuery promises to be enlightening in > this regard: while nobody wants redundancy, I also wonder whether > there's a "one size fits all" attitude. A juicy subject, indeed, > but that deserves a separate discussion... > > Powerful as XSLT is, its use in code-generation logicsheets doesn't come > without problems. > > Granted, most transformational patterns characteristic of code > generation > can be correctly and completely expressed in XSLT without resorting to > extension functions (wich, btw, are currently available only in Xalan). > > Their implementation, though, is usually too verbose and convoluted. > To illustrate the point, remember how one must declare dynamic tag > parameters so that they can be referenced as XSLT variables in source > code templates: tedious, repetitive, error-prone. > > String manipulation is also a problem area. Think of the complexity seen > in the "get-nested-string" utility template. Plus you guys need to stop including that code in every logicsheet. The re-use police will get you. > Indentation in generated code is also a problem. While, for most > languages, this is just an aesthetic consideration, there are other > cases in which it can become a real problem: think of [J]Python. I'd rather not :-D > A higher level language is called for and we all have known it for a > while now. That's what SiLLy is about. [SiLLy stuff snipped] While I think SiLLy could probably work well for you, I want to avoid thinking that it can be cross-language. It can't. But if AxKit decided to run with SiLLy (I'm still quite undecided), then I guess it could be a lot simpler to go from Java to Perl, but then again the object model is completely different, so I doubt it would be that easy. I think the best thing SiLLy has going for it is that it could potentially make documenting taglibs a lot easier. This is somewhere I've noticed that Cocoon is really weak at in comparison to the AxKit taglibs - all the core AxKit taglibs are well documented, whereas I don't think you guys yet have docs for Util, sendmail, etc (not that I've found anyway). The reason AxKit's taglibs are well documented is that we use Perl (SAX) to make our taglibs, so we have POD available to us for documenting them. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ From shelley94@example.net Mon Mar 5 10:47:12 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 56692 invoked from network); 5 Mar 2001 10:47:12 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 10:47:12 -0000 Received: (qmail 25126 invoked from network); 5 Mar 2001 10:47:22 -0000 Received: from unknown (HELO ?83.161.120.155?) (83.161.120.155) by mailgate.sergeant.org with SMTP; 5 Mar 2001 10:47:22 -0000 Date: Mon, 5 Mar 2001 10:44:20 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Ricardo Rocha <shelley94@example.net> cc: XSPDev <shelley94@example.net> Subject: Conclusions (Cocoonsions?) (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <shelley94@example.net> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 2 Mar 2001, Ricardo Rocha wrote: > - Capturing aspects in XSP Seems pointless to me. Plus I can't find anyone who understands aspects enough to explain it clearly to me :-) > - Making XSP a general-purpose factory for server components (other than > server pages) A Cocoonism. > - Refactoring XSP implementation to avoid "the same but different" > syndrome visible in the redundant implementation of server pages and > the compiled sitemap A Cocoonism. > - Avoiding "language impedance" by placing only pure markup in XSP pages > with no recurse to the underlying programming language Bad bad bad. > - Defining a logicsheet language: SiLLy A great idea for Cocoon. We'll examine it if it is deemed necessary to us, but it doesn't seem that way yet. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ From shelley94@example.net Mon Mar 5 17:50:07 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 5909 invoked from network); 5 Mar 2001 17:50:07 -0000 Received: from bells.cs.ucl.ac.uk (83.161.120.155) by h31.sny.collab.net with SMTP; 5 Mar 2001 17:50:07 -0000 Received: from douglas-3.dsl.easynet.co.uk by bells.cs.ucl.ac.uk with UK SMTP id <shelley94@example.net>; Mon, 5 Mar 2001 17:49:47 +0000 Message-ID: <009d01c0a59d$0b09bd10$0179a8c0@spukny> From: Allan Erskine <shelley94@example.net> To: Matt Sergeant <shelley94@example.net>, Ricardo Rocha <shelley94@example.net> Cc: XSPDev <shelley94@example.net> References: <shelley94@example.net> Subject: Re: XSP and Aspects (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) Date: Mon, 5 Mar 2001 17:52:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > What I'm hearing is that aspects are something that someone invented > because of the weakness of Java's dynamism. In Perl inserting a proxy > object to catch method calls and such is pretty trivial, so we don't name > it, that's just "programming perl" :-) > > Having said that, I don't think you've really identified a problem with > XSP, so I'm not sure what this would gain us. It seems like somebody's > pontification turned into an RT, without any real purpose. I don't think anyone was suggesting an explicit aspect construct. Rather we were just observing that well chosen markup can help capture aspects, these being items/features that would otherwise crosscut our system. Seeing as we're all engaging in this anyway, I don't see the problem in adopting "aspect" as our terminology, and using this terminology to shape our guiding principles. ----- Original Message ----- From: "Matt Sergeant" <shelley94@example.net> To: "Ricardo Rocha" <shelley94@example.net> Cc: "XSPDev" <shelley94@example.net> Sent: Monday, March 05, 2001 9:58 AM Subject: XSP and Aspects (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) > Note: I'm keeping these replies off cocoon-dev. I see no reason to CC > there - you're not CC'ing axkit-devel too. > > I'm going to try and reply to each one of these separately. > > On Fri, 2 Mar 2001, Ricardo Rocha wrote: > > > 1) Capturing aspects in XSP > > > > In Allan's words, capturing aspects in XSP boils down to choosing markup > > to represent and encapsulate what would otherwise be a crosscutting > > feature. > > > > To begin, XSP is generally seen as a (source) code-generation markup > > language. > > > > NB: Implementation-wise, though, it could be an _object composition_ > > language instead, with no need to resort to code generation > > except, perhaps, for supercompilation-like optimizations. (I'd > > like to elaborate on this later, on a separate post: a > > composition-oriented approach to dynamic XML generation based on > > Avalon patterns.) > > > > AspectJ (our reference for AOP) acts as a Java preprocessor thus also > > "incurring" in code generation. > > > > Aspects observe and react to object events such as method invocations or > > exception handling. AspectJ achieves this by inserting aspect-support > > code at appropriate spots (join points) so that the crosscutting feature > > is accounted for in a transparent and uniform fashion across different > > classes. > > > > OT: With the introduction of dynamic proxies in Java 1.3, > > preprocessing > > is no longer the only obvious option: it's now possible to trap > > method invocations and exception throwing using dynamic proxies. > > > > XSP code generation can be easily used for the same purpose although, as > > Stefano points out, XML syntax is very unfriendly with code (the > > "language impedance" issue commented below) > > > > Consider XSP page debugging: the XSP code generator could well adorn > > generated code to keep track of source lines in the XSP page and all > > intervening logicsheets. Thus, when an exception is thrown, this > > information would be used to dynamically generate an error page > > displaying the appropriate context for the generated source program, > > the original XSP page and all relevant logicsheets: an XSP developer's > > nirvana! :-) > > > > In fact, this wouldn't need to be the code generator's responsibility: > > an otherwise "regular" logicsheet could be applied that scans all > > <xsp:expr> and <xsp:logic> tags in order to append location info to the > > generated source program. All in an aspect-oriented fashion. > > > > Of course, there are many more implications to making XSP aspect-aware, > > but one could say that the basic mechanisms needed to achieve are > > already in place. > > > > If we refine the logicsheet applying mechanism and (ideally) also > > disallow embedding raw code in XSP pages (i.e., we base all dynamic XML > > generation on logicsheets) then capturing/representing aspects would > > become much simpler. (This is even more obvious under the composition > > model mentioned above.) > > What I'm hearing is that aspects are something that someone invented > because of the weakness of Java's dynamism. In Perl inserting a proxy > object to catch method calls and such is pretty trivial, so we don't name > it, that's just "programming perl" :-) > > Having said that, I don't think you've really identified a problem with > XSP, so I'm not sure what this would gain us. It seems like somebody's > pontification turned into an RT, without any real purpose. > > I'll come onto removing raw code in XSP in one of the other sections where > it's more relevant. > > -- > <Matt/> > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ > From shelley94@example.net Mon Mar 5 17:52:16 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 8893 invoked from network); 5 Mar 2001 17:52:16 -0000 Received: from bells.cs.ucl.ac.uk (83.161.120.155) by h31.sny.collab.net with SMTP; 5 Mar 2001 17:52:16 -0000 Received: from douglas-3.dsl.easynet.co.uk by bells.cs.ucl.ac.uk with UK SMTP id <shelley94@example.net>; Mon, 5 Mar 2001 17:52:02 +0000 Message-ID: <00ad01c0a59d$5b44add0$0179a8c0@spukny> From: Allan Erskine <shelley94@example.net> To: Matt Sergeant <shelley94@example.net>, Ricardo Rocha <shelley94@example.net> Cc: XSPDev <shelley94@example.net> References: <shelley94@example.net> Subject: Re: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) Date: Mon, 5 Mar 2001 17:54:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > All I can say to this is that under AxKit, it is already possible to use > XSP to generate XML anywhere, provided you can extract the generated code > (we don't save to a file like Cocoon does). The code is just a simple > handler function that gets invoked at execution time. The only time it > becomes uncallable from outside of AxKit is if it makes use of the $cgi or > $r objects. > > Plus AxKit has no concept of Generators and whatnot. That's all YAGTNI to > us. XSP is just another callable engine in the pipeline. > Ricardo's proposal is a move in this direction, with some great looking structural ideas to back it up. From what you say here, it looks like a convergence towards AxKit's way of doing things - so I'd hope you'd share our expectation that all XSP platforms could have something to gain. ----- Original Message ----- From: "Matt Sergeant" <shelley94@example.net> To: "Ricardo Rocha" <shelley94@example.net> Cc: "XSPDev" <shelley94@example.net> Sent: Monday, March 05, 2001 10:12 AM Subject: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) > Again, keeping this off cocoon-dev. > > On Fri, 2 Mar 2001, Ricardo Rocha wrote: > > > 2) Making XSP a general-purpose factory for server components > > > > Probably the most wasteful single mistake in the existing (Cocoon) XSP > > implementations is limiting code generation to Producers (C1) and > > Generators (C2). > > > > This undesirable "feature" stems from the fact that the last-stage > > logicsheet applied (the one dealing with the XSP tagset as such) also > > contains the compilation unit skeleton. > > > > If we decouple XSP from the target source program type and the > > invocation environment (e.g. http/servlet) then the XSP language could > > be used for building practically any kind of markup-generating program. > > I've snipped the rest because it's all cocoon-isms. > > All I can say to this is that under AxKit, it is already possible to use > XSP to generate XML anywhere, provided you can extract the generated code > (we don't save to a file like Cocoon does). The code is just a simple > handler function that gets invoked at execution time. The only time it > becomes uncallable from outside of AxKit is if it makes use of the $cgi or > $r objects. > > Plus AxKit has no concept of Generators and whatnot. That's all YAGTNI to > us. XSP is just another callable engine in the pipeline. > > -- > <Matt/> > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ > From shelley94@example.net Mon Mar 5 18:13:17 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 38033 invoked from network); 5 Mar 2001 18:13:17 -0000 Received: from bells.cs.ucl.ac.uk (83.161.120.155) by h31.sny.collab.net with SMTP; 5 Mar 2001 18:13:17 -0000 Received: from douglas-3.dsl.easynet.co.uk by bells.cs.ucl.ac.uk with UK SMTP id <shelley94@example.net>; Mon, 5 Mar 2001 18:13:10 +0000 Message-ID: <00b301c0a5a0$4ef93840$0179a8c0@spukny> From: Allan Erskine <shelley94@example.net> To: Matt Sergeant <shelley94@example.net>, Ricardo Rocha <shelley94@example.net> Cc: XSPDev <shelley94@example.net> References: <shelley94@example.net> Subject: Re: Avoiding "language impedance" in XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) Date: Mon, 5 Mar 2001 18:15:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > Embedding code in markup not only breaks encapsulation: it hinders > > reuse! > > I think you're wrong here. Way off base. While I understand you're talking > about this from a theoretical standpoint, you cannot ignore the practical > issues. People can cope with <foo:do_something_major/>, but they don't > like doing <xsp:if> or whatever the equivalent would be. There's just so > much that a programming language can do, and a taglib can't. Side effects > being the one major thing that springs to mind. OK this seems to be a fairly large difference of opinion, but I don't think it's irreconsilable. First can I point out that our suggested solution to "language impedance" within XSP could be made entirely optional on the developers part...although I'd prefer direct language access to become disabled by default (with a mechanism to explicitly enable it). > In short, I think you're focussing on it incorrectly: > > The re-usable component is the generated XML - not tiny parts of the > XSP page that you might be writing to build that XML. And putting > code in XSP doesn't kill that notion in any way shape or form. On my first reading of Ricardo's email, I thought his focus was bang on. <xsp:if> is exactly the sort of direct programming construct that we DON'T want to need to use. You rightly say that programming languages can do a lot...however so can taglibs, and they have the potential to be exactly aligned to multiple dimensions of the entire XML serving domain in ways no (current) general purpose language could (not even Perl). So IMO it comes down to much more than just reuse. ----- Original Message ----- From: "Matt Sergeant" <shelley94@example.net> To: "Ricardo Rocha" <shelley94@example.net> Cc: "XSPDev" <shelley94@example.net> Sent: Monday, March 05, 2001 10:26 AM Subject: Avoiding "language impedance" in XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) > On Fri, 2 Mar 2001, Ricardo Rocha wrote: > > > 4) Avoiding "language impedance" in XSP > > > > This is a tough one: server pages developers seem to love the ability to > > embed "raw" source code in markup, a trend originally set by M$'s ASP > > and later embraced by JSP and XSP. > > > > While this has the appeal of enabling quick prototyping, we have come > > to suspect that _any_ language-specific programming constructs in XSP > > break encapsulation and are, therefore, WRONG! > > > > Embedding code in markup not only breaks encapsulation: it hinders > > reuse! > > I think you're wrong here. Way off base. While I understand you're talking > about this from a theoretical standpoint, you cannot ignore the practical > issues. People can cope with <foo:do_something_major/>, but they don't > like doing <xsp:if> or whatever the equivalent would be. There's just so > much that a programming language can do, and a taglib can't. Side effects > being the one major thing that springs to mind. > > In short, I think you're focussing on it incorrectly: > > The re-usable component is the generated XML - not tiny parts of the > XSP page that you might be writing to build that XML. And putting > code in XSP doesn't kill that notion in any way shape or form. > > Taglibs are great, but they are never going to be trivial to implement, > and that is *A GOOD THING*. Its like the difference between classes and > code that uses those classes. Writing the classes is harder than writing > the code that uses the classes, and so it should be done with a clear > design and requirements document. Writing the code that uses those classes > needn't be that way. > > > This whole point seems to boil down to the following: > > > > All that can be achieved by embedding code in markup can also be > > achieved by inlining the invocation of a suitably defined method > > on a suitably defined object. > > Just because you can, doesn't mean that you should. > > -- > <Matt/> > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ > From shelley94@example.net Mon Mar 5 19:34:43 2001 Return-Path: <shelley94@example.net> Mailing-List: contact shelley94@example.net; run by ezmlm Delivered-To: mailing list shelley94@example.net Received: (qmail 46042 invoked from network); 5 Mar 2001 19:34:43 -0000 Received: from mailgate.sergeant.org (HELO mail.sergeant.org) (shelley94@example.net) by h31.sny.collab.net with SMTP; 5 Mar 2001 19:34:43 -0000 Received: (qmail 3835 invoked by uid 501); 5 Mar 2001 19:34:48 -0000 Received: from localhost (shelley94@example.net) by localhost with SMTP; 5 Mar 2001 19:34:48 -0000 Date: Mon, 5 Mar 2001 19:34:48 +0000 (GMT) From: Matt Sergeant <shelley94@example.net> To: Allan Erskine <shelley94@example.net> cc: Ricardo Rocha <shelley94@example.net>, XSPDev <shelley94@example.net> Subject: Re: Avoiding "language impedance" in XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects)) In-Reply-To: <00b301c0a5a0$4ef93840$0179a8c0@spukny> Message-ID: <shelley94@example.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Mon, 5 Mar 2001, Allan Erskine wrote: > > In short, I think you're focussing
{'source': 'Apache Software Foundation Public Mail Archives'}