cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Erskine" <>
Subject Re: [RT] Rationalizing XSP (was: XSP and aspects)
Date Fri, 09 Mar 2001 13:49:21 GMT
Thanks to Ricardo for the excellent email......

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


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

This is shooting much higher than I was at first!  In my initial email, I
wasn't actually intending that we make XSP more aspect aware...I was just
saying that it looks like XSP is good for capturing aspects.  (This
now seems kind of obvious, given an XSP engine's and AspectJ's similar roles
as code preprocessors)

But the more I think about it, the more I think 'why not'?  If
capturing aspects is what we're doing anyway, and if it seems that XSP is
good at it, it could be very interesting to experiment with how we can make
this explicit within XSP (or a taglib - see later).


> Probably the most wasteful single mistake in the existing (Cocoon) XSP
> implementations is limiting code generation to Producers (C1) and
> Generators (C2).

It would be amazing to be able to "fix" this in time for C2.

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

OK - I've had a bit of a spiel with Matt Sergeant on XSPDev.  The conclusion
we reached was that XSP is already semi-decoupled from the invocation
environment, since the XSP spec doesn't insist on an XSP root element tag.

This would leave us free to have a sitemap or flowmap, say, as taglibs:

<xml-server:process       (or cocoon:sitemap, although I think it's better
to leave the root tags as general as is appropriate, so they can be used
cross-platform at the least)
        language="java"     (defaults to this)
                (ideally defaults to this, for all root tags other than
                    xsp:page, for backwards compat)
        xmlns:fmap=""      (assuming flowmaps
aren't 'orthogonal'!)

This is currently valid within XSP, and to integrate into C2 or AxKit would
only require pre-processors looking out for root elements appropriate to the
component type to construct.  For example, the <xml-server:process> would
correspond to a top-level component in an abstract XML request/response
environment (such as C2 in a servlet).

We could even make it easier to remember which file is which by altering the
filetype, as is done with sitemap.xmap.  Mind you, this seems a bit

Presumably anything else we want to achieve, be it implementing aspects, or
rationalising sitemaps within XSP, could all be done by choosing a new root
element type or by some taglibs.

My only problem is it's impossible to express the purpose of new classes of
server entities other than pages (eg the sitemap).  XSP is flexible enough
to construct server components other than page-generators, and nobody would
want to input a sitemap into a page-generator, therefore I'd seek a stricter
separation by having new root element types within the XSP namespace, eg
<xsp:process> or <xsp:transform>, and enforcing the separation in the XSP
code generation stage.

The trouble with this is that is would require changes to the XSP spec, and
Matt quite rightly insisted on _very_ proper justification for this to

We left the discussion hoping for some other people's opinion...please help
us out, as there are good arguments either way...

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

We didn't really cover this on XSPDev.  I'd say that a good initial
compromise would be to disable language embedding by default on all root
element types other than <xsp:page>, where it would remain enabled by
default for backwards compatibility.  Then programmers wouldn't think twice
about enabling it for their wicked pursuits, but newcomers could happily use
all the taglibs without worrying about code.

> 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).

This, I'm beginning to think, is a fantastic idea.  The worst that could
happen is that it would become a null-stage, to be optimised out if nobody
used it.  But I have a feeling it could become a _primary_ stage, and might
be a watermark for webapp development.  Imagine how many changes are
currently involved if a new field needs to be added in a database web-app
(to all the forms, labels, selects, inserts, updates, ...).

Imagine if only one change needed to be made; one change covering that whole
aspect.  Idealistic, of course, but it would be good to think we can
approach this...

And the great thing is it would just be another taglib!

> 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

This decoupling seems vital to me.  But I personally would like to see
the decoupling fully represented by separating at the XSP root tag level (ie
new XSP root tag names, like <xsp:transform>).  Matt thinks it would be
wrong to pollute the XSP namespace with what could potentially be a large
number of new root tag types.  We left our argument hoping for new input...

> 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)
> 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)
> - Taglibs/logicsheets
> - Aspects

I took the liberty of reordering this list into what I regard as decreasing
order of generality/applicability.  I've also bunched together those that
have strong mutual coupling.

> - Taglibs/logicsheets

This is what marks up everything, and forms the extensible language, so has
to be top, IMO.

> - Aspects

Could be implemented in taglibs, but then would be applicable across broad
ranges of XSP code.

> - Invocation environment (http/servlet, command-line)

I've placed this next because it's the basis of what new XML server
components we may wish to generate with XSP.  If we agree to characterise
these potential new components by their
'invocation environment', then I'd include page, transform, and "abstract
request/response model" along with those mentioned.

> - Program type (compilation unit skeleton: Generator, Transformer, etc.)
> - Programming language(s) (Java, Javascript, NetRexx, etc)

I've grouped these together, since in Cocoon they are tightly coupled.  And
following my discussion with Matt, I think Cocooners need to worry more
about the first item than AxKit.  The second item of course is where Cocoon
should come into its own...


Hopefully this will be abstracted away soon in all implementations of XSP.

An item I'd add to this list would be

 - XSP spec issues (such as xsp namespace usage, and root element usage)

> 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.
> Fortunately, the solution is obvious: deprecating MarkupLanguage and
> adding a separate program skeleton logicsheet step in the XSP code
> generation pipeline.

I'd love to see a start on this solution, and to help...

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

While I totally agree, I think it will be the last thing to go, at least for
server pages.  I agree with Matt that server-pages developers are too
entrenched in having a programming language to give it up.  There needs to
be a fantastic new way of doing things for this to ever happen.

Having said that, for all new server components other than pages,
language-embedding should be disabled by default.  This encourages good
style, and more importantly, good taglibs like the sitemap.

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

True, and very important.  Following this reasoning, XSP must become a
canonical (XML) language for dynamic XML.  It should be used across the
board.  The first new place I'd put it would be in Prowler!

> 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.)

This is sounding too good to be true.  The future has arrived when an
aspect-aware component model becomes the norm for web-app development (the
least aspect or component oriented field in all computer science!).  Where
do I sign up?


> 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

I'm really all for everything you're saying.

> 5) Defining a logicsheet language: SiLLy
>    NB: Logichseets are far simpler in AxKit (Perl). Boy, are they lucky!

With the component based approach you mention on the table, and with all
language issues out the way, SiLLy is going to be easy to implement, and a
boon to taglib authors.

Until then though, I suspect that SiLLy could be difficult to maintain as
specs fluctuate.  It would be a complex entity tightly coupled to complex
transitory entities on both sides (silly programs <-> logicsheets).  I'm
assuming this is why it's not here now, despite looking damn handy.

Great RT though.  It would be cool to see it happen, and I'd like to help if

 - Allan

> Un saludo tropical desde la Tierra del Olvido!
> Ricardo

To unsubscribe, e-mail:
For additional commands, email:

View raw message