cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Fri, 26 May 2000 23:31:53 GMT
David Wagner wrote:

> > Well, it's irrelevant to you that never wrote web-applications :)
> > Anyway, I understand your point.
> >
> Which illustrates the design difference (not a flaw at all, perhaps
> just a different target user of these systems) I was getting at.


> Though I have written some fairly involved web applications, most web
> publishers (as far as I can tell) have not, nor do they know this is
> what they are doing when tossing a bunch of stuff on a server and
> saying, "Hey!  Let's just put this stuff in a database and make all
> the pages come out in a standard template!"

Yes, but the world will need the figure of "XSL-ist" soon. A job that
already has a huge request.
> I am trying to consider what the user of Cocoon2 or another publishing
> system is likely to do with it, regardless of what the package is
> actually capable of doing.  

Ok, good point view.

> For the most part (and this is what I
> _think_ is a reasonable assumption), most of what publishers want to
> do is publish stuff.  

This is evident :)

> Every once in a while someone will think of
> something truly new to add to a site (a new kind of resource needing
> high-level programming), but for the most part publishers mix, match,
> and customize a set of fairly common components along fairly stable
> layout lines.  

Correct. Those "layout lines" are a special form of "contract", a
"contract" being what connects two different working contexts (a.k.a.
known as "concerns areas").

What you are stating can be reformulated as "contracts change
unfrequently". Which is the very first assumption of the idea of
"separation of concerns" that is the main design pattern behind Cocoon.

> Also (a personal observation), a frightening large
> number of web publishers have no inclination to learn any kind of
> structured techniques, be they programming or markup languages.  

This is _very_ likely to change once you show them the abilities you
obtain by doing so. Also, XML defines validation and bases most of its
power on this.

> "Cut
> and paste until it works in IE4.01 and NN4.06," seems to be the
> programming 'style' of all of those I have worked with in the US
> Government and in small to middlin' business.  (For business there is
> a strong incentive for a _lack_ of forward-compatibility: planned
> obsolescence; the same business is likely to get the contract to
> rewrite the same site over and over for every major browser release.)

We never tried to hide that Cocoon-based systems have a much steeper
learning curve.

But we say the plateaux is almost flat when you reach the top of the
curve :)

> > This is another way of expressing a sitemap, right into the
> document,
> > unfortunately, this requires client side operation, it has
> > nothing to do
> > with server side: what does it mean to "embed" a Gif image into a
> > document on the server side? write the <img src=""> tag? include the
> > binary as CDATA?
> >
> Client side operation?  I never considered running anything client
> side...  Hmmm... That's an interesting idea...

Well, XML started on the client side... it was my personal idea (back to
December 1998) to move it on the server side to avoid waiting for
browsers to support those very nice ideas.
> Ah, but to answer your question, it could be either, depending on the
> type of document delivered; 

Right. The question remains: how do you know? special extended-XSLT
stylesheets with hooks to the request parameters? Sorry, but I don't
think this is the path to simplicity.

> xlink:show defines where the resource is
> to display on the user's system.  For XHTML, the server would create
> the appropriate link to the resource such that it will display in the
> client at the right place, say as an img element (causing the client
> to generate a seperate request for the image itself).  For WML and PDF
> versions, an embedded image would be encoded and delivered with the
> document, as their standards specify.  XLINK defines
> xlink:show="embed" as, "An application traversing to the ending
> resource should load it for display in place of the starting
> resource... ...embedding affects only the display of the relevant
> resources; it does not dictate permanent transformation of the
> starting resource." []

I know that, the problem is _how_ the server knows this for every
possible format language supported on the client side. Sorry, but I
think XLink is mainly useful on the client side.
> I am considering how to use xinclude for resource inclusion in
> delivered markup  to allow SVG and MathML to be (optionally) included
> directly in the delivered document.  Why optional?  There's no need to
> waste bandwidth including your stunning SVG logo on every delivered
> page when it can be embedded and cached in your client's computer as
> mystunninglogo.svg.

Right. This is why URIs were created in the first place. And why Cocoon
reacts on URIs.
> > well, I'm not so sure you fully understand the paradigm shift
> between
> > server side and client side.... If we had a perfectly capable XML
> > browser with all xml, xslt, xslt-extentions, xlink, RDF, SVG
> > and XSL:FO
> > in place, there will be very little need for Cocoon or anything like
> > that.
> >
> OOooh...  Hmmm...  (btw: all my recent work has been on server-side
> apps, except the client-side search page I needed to write for a CD
> distribution of the contents of a web site; I am quite familiar with
> the difference. :)  Interesting idea, but I disagree with your
> conclusion.  IMHO, there would be even _more_ need for publication
> site management tools, though such tools will need to be scalable both
> UP to the international organization and DOWN to the individual user.

Good point. I agree there will always be the need for Cocoon and even
for more advanced systems... but, please, one step at a time :)

> Anyone thinking about Cocoon3 yet?  

Oh God, please, don't!

> (Suggestions: 
> i18n, 

already implemented in Cocoon2

> WAI Triple-A,

what's this?

> 100% open standards

are you kidding? do you see any proprietary standard around?

> stunning front-end

well, we'll get there, don't worry :)

> name: Mothra ;)

No way! Cocoon is too cool to be changed. :)

> > The problem is we _don't_ have these clients and we must _fake_ them
> > using server side operation. Unfortunately, things work kind of
> > different when distributed in client/server enviornment.
> <snip/>
> > This is highly subjective and clearly dependent on your programming
> > background and mindset. Anyway, XSP and XSLT-extentions are
> completely
> > equivalent in functionality, this has already been analyzed, but
> they
> > represent orthogonal views of the same world.
> <snip/>
> > Totally. But, sorry, I still don't understand where is the design
> flaw
> > you underlined in your first email.
> >
> Ah, well, I think these systems have much more in common than
> different, and I haven't found any design flaws, just a few
> differences probably related to my timeline being set to incorporate
> W3C X-standards as they stabilize to minimize the faking needed, and
> to the intended users of these systems.  I am designing so even small
> organizations (think individual activists) can get the good content
> they have on the web and available to the greatest number of people
> efficiently and effectively.

Ok, this clarifies your vision.
> Thank you muchly for your thoughtful and considered responses to my
> lengthy queries and explanations.  You have greatly increased my
> understanding of this project, and of my project as well.  It will
> help when writing and editing the documents y'all need.  I continue to
> look forward to working with you and this fantastic team.

Same here. It's always a pleasure to test our ideas against different

Thanks for joining us.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message