Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: niclas@envision.asiaconnect.com.my
Message-ID: <38C0E1ED.B1DE98C9@localbar.com>
Date: Sat, 04 Mar 2000 18:14:05 +0800
From: Niclas Hedhman <niclas@localbar.com>
Organization: Bali Automation Sdn Bhd
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Layout-driven vs. content-driven
References: <Pine.LNX.4.10.10003022320430.5760-100000@phoenix.webslingerZ.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Leventhal's arguments + excellent counter arguments by you guys, drive me to
summarize;

a) At the time of the writing, XSL was a mix of XTL and FOL (Stefano's abbrevs).
Most of the article is attacking FOL, only to a lesser degree XTL.

b) The choice of using XTL or programming at the server side is an individual
choice, and matter of preferences. Cocoon allows both to happen, to accommodate
for various requirements.

c) Server side genereated FOL rendering is a rather bad thing. A XML document + a
FOL stylesheet (possibly also some XTL?) should be processed at the client. It
will however take yet quite some time before we will see these clients emerge.

d) Interactive documents, so much celebrated in Mr Leventhal's article, is perhaps
not as common as people believe. Interactive documents are not, IMO, pages that
flashes, beeps and do something upon user action. But instead, where there is a
link maintained, somehow, from the original source document and the visual
presentation on the client. This is especially a case for non-browser clients,
which should be dealing with raw XML and an associated stylesheet. When the client
modifies the XML document, the rendering must opccur again, and if this is a 1 sec
process, it is not really acceptable. However, I believe this a bit peripheral to
the current developments on the web.

e)  Whether XSL is a difficult languages or not, is very much personal preference.
I tend to think it is utterly complex, and almost impossible to get it to do what
I want (except simple things). But then again, I am trying hard stuff, and I am a
traditional programmer.

f)  Mr Leventhal is advocating full adherence of clients to existing standards
prior to devulging into new ones, on the basis of "compatibility". This is a good
thing, and we will probably never see it happen, no matter how much we want. Today
it is just about impossible to make anything on the web to appear the same, at
pixel level, on the 2 dominating browsers or the latest version, let alone older
versions and the dozen or so more peripheral ones.

g)  Mr Leventhal's adovacy for CSS is possibly derived from his disappointment of
compliance among the existing CSS1 capable browsers (Anyone tried  :o)  ?? ) and
he wants so much for CSS to work for him, and that's why he sees XSL as threat
that CSS will never be fully supported.


I conclude, Cocoon is not shutting the door for anyone, not even Mr Leventhal, at
the server side. You want programming languages instead of XTL, you got it.  You
want CSS to be delivered to the client, you got it. The strength of Cocoon is its
ability to compensate for the client's capability, and clients with new and other
features, such as WAP, VRML and voice.
I believe we will see a few very interesting variations on how Cocoon is deployed,
today not contemplated.

I thank you all for your comments and angles. To some I agree, to some I don't,
but that is mostly personal preference.

Niclas