cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Erskine <>
Subject Re: [C2] XSP and apects (was: log performance penalties)
Date Thu, 01 Mar 2001 10:46:25 GMT
that reply was a great relief - thanks!  I was beginning to wonder if I was
missing the point...

----- Original Message -----
From: "Stefano Mazzocchi" <>
To: <>
Cc: "Ricardo Rocha" <>
Sent: Tuesday, February 27, 2001 12:01 PM
Subject: Re: [C2] XSP and apects (was: log performance penalties)


> Allan Erskine wrote:

> > Assuming a "concern" in this context is taken as delimiting a
> > broad area of interest, such as presentation or application logic, I
> > believe that my use of the word aspect is actually closer to what it
> > means in AOP, namely a feature that crosscuts many system components.
> Well, "concerns" and "aspects" are different things, the second more
> granular than the first.
> Visual example: if you give me a "concern" as a 3D object, I percieve
> its "aspects" as its projections (shade) to a plane. Of course, there
> are an infinite number of projections of a 3D object onto a 2D plane
> (you just have to move the plane around the rotate its normal!).
> So, there are "areas of interest" (concern islands) that share the same
> concerns, this automatically forces the sharing of the aspects these
> concerns convey.
> But different concern islands might share the same aspects... in fact,
> it's pretty easy to come up with a list of aspects that are shared by
> all concerns. For example, the concept of "useful" is an aspect, not a
> concern because it applies to concerns and discriminates them, but
> doesn't uniquely identify one.
> This is the terminology I use so hopefully this would remove some
> terminology problems that might emerge.

OK...sounds very reasonable, and probably more generally applicable than my
terminology which is closer to the notion of design aspect (lifted from the
aspect J primer).

Design aspect:  A feature that crosscuts other design components.

My definition of an implementing an aspect would be any implementation that
captures (and preferably encapsulates) a design aspect (removing the
crosscutting from the implementation).

An implemented aspect could be considered as "encapsulated" if it were
impossible to reproduce whatever was encapsulated outwith the
implementation's constructs.  Obviously this could be nigh-on impossible in
a general purpose programming language...but in XSP, with appropriate
control over logicsheets, and restricting the use of the underlying
programming language, it could be very possible....and well worth going for!
Actually what I'm harping on about would probably be the analogue of
separating concerns.

> > The difference between implementing aspects in a general purpose
> > language (like Java) and implementing aspects in a restricted purpose,
> > extensible language (like XSP) lies in the manner in which aspects are
> > modularised/captured.
> Agreed.
> > In aspectJ, the aspect construct is provided as a modularisation unit
> > crosscutting concerns.
> Well, no, this is not how I see it (but it's a personal opinion, not an
> objective truth): the above seems to indicate there is no difference
> between a concern and an aspect, being one the technical implementation
> of the other.

whoops, sorry, I meant crosscutting _feature_.  It's hard to avoid using
such a general word as "concern"!  Didn't mean to set you off :)...

> I'd like to keep the two things separated: my concern might be the
> visual presentation of information, the aspects of the problem are
> "usability", "friendlyness", "politeness", "visual coherence", "error
> support", etc...

I'm with this...aspect!=concern

> If your concern is writing application logic, aspects are "visibility"
> (logging), "stability" (concurrency, memory management), "security",
> "modularity", "coherence", "simplicity", "reusability", "longlasting",
> etc...
> Many of this "aspects" are implicitly bound into the programming
> language, or the programming paradigm: this is what 'high level' means,
> more aspects are taken into consideration by the programming language or
> contract design.
> In fact, design patterns are aspects frames: they give you the "shape"
> of the object and if you use that shape, you automatically have some
> shades, thus some aspects.

yep - some design patterns naturally have a design aspect since they
crosscut components, or involve collaborating components.  What a lot of
good design patterns have been struggling with has been the lack of good
ways to implement an aspect.  Apart from....

> Java is so good at this because it has the "interface" concept: without
> interfaces, Java would be just another OOP language. So, it is entirely
> possible to associate one aspect to one interface and use multiple
> interface extension as a cure to the ugly OO multiple inheritance.
> Guess what? This is exactly what we designed in Avalon: the only
> existing AOP framework that doesn't require Java syntax modifications.
> Look at Cocoon2 in
> public class Cocoon
>    extends
>       AbstractLoggable
>    implements
>       Component,
>       Initializable,
>       Modifiable,
>       Processor,
>       Contextualizable {

*clink* (penny dropping sound from someone just newly arrived from C++)


> Yes, entirely. But this is where I see the problems: just like Java was
> not designed for multi-dimensional separation of concerns in
> programming, XML wasn't either!
> XML is the first widely known model that allows multi-dimensionality
> (with namespacing) and since XSP makes heavy use of this, it seems
> logical to percieve an increased functionality and aspect orientation in
> a fully multi-dimensional syntax.
> But this rings a bell in my head: are you sure that it's really XSP that
> you like? or rather a collection of "aspects" that XSP itself has?

Nope.  Definitely XSP that I like.  Although you're right in what you say, I
don't think I'm shooting quite as high as you.  I'd like to see better AO
languages, but for now, for my XML server processing, I like XSP because I
can use logicsheet tags to encapsulate what would otherwise be crosscutting
features.  I'd like to be able to have this power in areas of my XML
processing other than just pages.

> Would it be better to take the good part of these aspects and carefully
> craft a syntax extension for the Java language, much like the AspectJ
> folks are doing, rather than use XSP a skeleton to provide
> multi-dimensionality to mono-dimensional programming languages?
> Hey, look: I don't have an answer for this! I've been fighting with the
> limitations of the OOP paradigm since I proposed the creation of Avalon
> three years ago and I've been very happy to find many people like you
> impressed and intrigued by these new concepts such as SoC, AOP, design
> patterns and all other modern software engineering paradigms.
> But deep in my heart, using XSP as a way to turn an OOP language into an
> AOP one, it's a hack: sure, it can be done, but it might include hidden
> mistakes that are not visible at first. One is the XML markup syntax
> which is totally code unfriendly. Another is the intrinsic complexity of
> the XML model: maybe there is a simpler syntax to add these concepts.

In the future, for sure...but for now, I'd be happy to see XSP become a best
of breed XML processing language, no matter how unsuitable XML may be for
languages!  It would seem unrealistic to think of dropping the XML from XSP
at this stage!


> > I was thinking here of XSP's potential as a
> > general purpose factory for server components other than
> > would be a
> > natural for this as it has already started to prove itself as an
> > technology;  it would make my life simpler for one to have that
> > in component construction available from sitemap calls other than
> > map:generate.
> Ah, now I get you: yes, Ricardo and I have been talking about this
> extensively, on how to use the concepts of XSP to generate other parts
> of Cocoon rather than generators.
> Of course, transformers come to mind

They certainly do!  Definitely a logical step after generators...especially
with sub-pipeline aggregation on the way, could be just the job to address a
bunch of web-app aspects.  Is this what you had in mind?...

    (access to sax input stream and sax output stream.  Consider restricting
access to underlying language, so everyone has to write useful logicsheets)
    (bunch of useful logicsheets based round XMLFilter)
    (and SAXPath!  whoops, got carried away there...)


> > Decreasing learning costs and improving maintenance is my middle name!
> Great to hear that :)
> > And also _would_ be a potential benefit of expanding XSP's remit.
> > Decreased learning cost - you just have
> > to learn XSP.  Decreased maintanence - XSP markup has demonstrated it's
> > utility in separating concerns, and capturing aspects.
> You'll be happy to hear that this is exactly what we discussed: how to
> make XSP 1.1 more general (one thing is to allow to avoid the use of the
> xsp: namespace entirely) and separate the code generation from the
> aspect aggregation semantics.

yessss.....but would removing the namespacing not bump the version up to XSP
2? (wouldn't be backwards compatible would it?)

I agree removing the namespacing would make xsp much more accessible, but
the changes I was thinking of were more minor, and wouldn't break any
compatibility.  I was just thinking of adding a couple more xsp types other
than xsp page, that would be distinguished by what was permitted within
each, namely

    no sax output, and preferably not much control over servlet or cocoon
components other than action parameters (any ideas how you'd separate this
out?!).  Access to underlying programming language.

    full control over request/response mechanism and other cocoon
components, but no access to underlying programming language (except through
logicsheets).  The sitemap (and sub-sitemaps) would be one of these.


page would be left the same to maintain compatibility, although ideally
would be

    control over a sax output stream, no access to underlying programming
language (except through logicsheets).  Gentlemans agreement among
logicsheet authors not to do anything that should really belong in
<xsp:action/> (preferably enforcable, but this would be difficult)

These are really just my first thoughts, so there's probably alot to
criticise here...

> But we decided to wait until the Cocoon2 core design stabilizes before
> sparkling yet another design quest. Hope you agree with me that too many
> design irons in the fire could dissipate all the creativity energy and
> kill the fire.

Oh, of course, I agree.  Still, a little R&D never hurt anyone....;>

> > Following this line of reasoning, the first thing you'd add to XSP would
> > the option to insist on only pure markup in an XSP page, no recourse to
> > underlying programming language.  This is definitely a direction I'd
like to
> > see for XSP, since it would encourage good style and portability, as
well as
> > the development of more powerful, flexible, and self-contained
> Great! This is *exactly* why we want the xsp: namespace out of the way!
> You should be able to write things like
>  <page>
>   <para>Today is <date:today/></para>
>  </page>
> and forget it!

I'm all for this...! (when the time seems right)

> This allows you to go to document writers and say "look, if you want the
> date, use this tag and it will magically appear". This more or less the
> same concept of word processor "fields" and writers love them!
> Forcing them to encapsulate the page into
>  <xsp:page>
>   <page>
>    <para>Today is <date:today/></para>
>   </page>
>  </xsp:page>
> is not different from something like
>  <?xsp?>
>  <page>
>   <para>Today is <date:today/></para>
>  </page>
> which is totally bad!!! (as 10 years of HyTime limbo clearly showed!)


> Anyway, the ultimate goal for XSP is to be so thin it becomes
> transparent :)

For pages, certainly, sounds great!

> > could ensure markup mixing only occured up to the point anticipated by
> > logicsheet authors (if this were appropriate).  For example a sitemap
> > logicsheet could declare that the flowmap logicsheet was the only other
> > permissable markup in such hypothetical XSP components.  This again
> > help enforce separation.
> Agreed. This is where the SiLLy language comes in, but Ricardo should be
> the one to talk more about this.

I liked the sound of SiLLy when I first arrived in's bucked the
trend of C2 components already, by appearing in the docs months before being

> > I used the term rationalised because at the moment the sitemap and XSP
> > need to be pre-compiled, cached, re-compiled, aggreated, etc in two
> > but different ways.  If another technology, eg a flowmap were to be
> > that operated in a third "the same but different" way, would this not be
> > indicator that a unification should be sought?  Such a unification would
> > presumably rationalise parts of the codebase.
> Have you talked with Ricardo lately? :) Gosh, these are more or less the
> same words he's been using. I'm positive that if you give him a hand,
> he'll be pleased to show you his intentions for this 'rationalization'.

Well I'd be very pleased to see them, and of course I'd like to help.  I've
been struggling up the C2 curve since Xmas, but I'm getting into it, and
have the debugger set up....

> > XSP's current an future structure is (and should be) an open invitation
> > extension, integration, and continued development.  I need convinced
> > the same can be said as easily of the sitemap.
> Agreed, even if solidity of contracts (that is markup, interfaces and
> the like) is a great value and back incompatibility must be sacrificed
> for the sake of 'elegance' only when it's valuable to do so. (like we
> did with Cocoon2)

The good thing about C2 though is that it's so flexible, and so much of this
is already implemented, it would all slot right in I'm sure....

> That's great.
> Ricardo, if you find the time, this call is for you :)


- Allan

> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

View raw message