cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Lewis <Andy.Le...@NSMG.VERITAS.com>
Subject RE: [RT] Layout-driven vs. content-driven
Date Fri, 03 Mar 2000 14:16:39 GMT
I actually went through this article, and the arguments in general well
before I implemented Cocoon. I fundamentally disagree with the author
however. I know I'm not an active member of this list (mostly lurk), but
I've successfully implemented Cocoon to drive the external web site for
VERITAS Software - a fairly large scale real-world scenario. 

-	XSL Has Nothing new for the Web

ok, technically, yea. True. There have been other ways to handle everything.
But I can teach a technically minded content author who knows almost NOTHING
about actual programming to go to town on XSL. If the transformations needed
to represent the site here had to be done in a procedural language, rather
than declarative, such as XSL, I would not be running the site on XML today.
XSL moves the scope of the transformation into presentation format into the
scope of non-programmer, though still technical staff. That is CRITICAL in a
corporate effort at least. I recently worked with an individual who insisted
that I should be using ISAM data storage and hand coding all of my table
joins for efficiency. Same kind of thing here. Why would I do that when I
can put it in SQL and throw MS Query or the like at any marginally competent
user and be done?

-	XSL Does Not Support Interactive Web Documents

I have XSL driven forms all over the place. The transformations make it a
breeze to abstract things like validation into a simple attribute in the
source document identifying data type. I also mix XSL and JavaScript quite
happily. I've done it, and it's very clean. Interactive documents on the web
are an interesting challenge now matter how you slice it.

-	Semantic Information Threatened by XSL

This is clearly a FO issue. I know little about FO, and use it less. If I
ever need to generate a PDF, I guess I'll look into it. :-)

-	XSL is an Ugly, Difficult Language

Purely subjective. Have you ever tried to teach a graphic artist C++? I'd
much rather teach XSL. In addition, a visual editor for XSL style sheets is
quite doable. Not quite so easy without it.

-	XSL has Set Back the Web at least two year

This is mostly a rant IMHO, and quite frankly if MS was going to implement
full CSS, they would have done so some time ago. Lack of CSS support in
browsers has little to do with XSL. Neither major browser has bothered to
implement properly if at all numerous part of other standards as well. If
everyone focused on the standards that are already in place, XML itself
wouldn't exist. Laying corporate ignorance at the feet of XSL doesn't buy
much.

I apologize for the long post, but I went through this at length with my
team before moving in the XSL direction. The decision was unanimous XSLT,
and Cocoon, and it was worked very well.



Andy Lewis
VERITAS Software, Heathrow, Florida
Voice:  407-531-7584  -  Fax:  407-531-7686  -  Cell:  407-718-4718
Pager:  4077184718@mobile.att.net  -  EMail:  andy.lewis@veritas.com
<mailto:andy.lewis@veritas.com> 

" Some days, it is best to keep reality at arms length..."


		-----Original Message-----
		From:	Donald Ball [mailto:balld@webslingerZ.com]
		Sent:	Thursday, March 02, 2000 11:37 PM
		To:	cocoon-dev@xml.apache.org
		Cc:	michael@textscience.com
		Subject:	Re: [RT] Layout-driven vs. content-driven

		On Fri, 3 Mar 2000, Niclas Hedhman wrote:

		> Stefano Mazzocchi wrote:
		> 
		> > FO is great, IMO, but it's a pain to learn from the
spec... almost
		> > impossible without visual descriptions of the formatting
layout. But as
		> > soon as you have visual tools for that... shees, have
you seen the SVG
		> > example with the Adobe SVG Viewer as Netscape plugin?
no?
		> 
		> I just read an article by Michael Leventhal
		> (http://xml.com/pub/au/Leventhal_Michael) regarding XSL in
general, and FO in
		> particular.
		> 
		> It is a bit old, but I think it is relevant in our
context.
		> 
		> http://xml.com/xml/pub/1999/05/xsl/xslconsidered_1.html
		> (terribly slow site...)
		> 
		> Sad(?) to say; he managed to convince me on a lot of
points.
		> 
		> The article put forward some challenges, and I would like
to see what
		> kind of arguments the Cocoon users/developers have to
defend their
		> choice, or have we all been blinded by a "XSL
anti-pattern"??

		I think we all agree that we need seperation of content and
design. XML
		gives us a data management layer, these articles are
questioning the use
		of XSLT as the data presentation layer. They seem to be
advocating CSS and
		client-side javascript as their alternative. That may well
be a good
		solution for some applications, but I prefer usually XSLT.
Why?

		1. XSLT is general - it allows you to transform XML into
other XML or
		HTML. CSS+javascript is fairly closely tied to the 2D
graphical browser
		window paradigm.

		2. XSLT is XML. CSS is not. Is there any good reason to
learn and use two
		different syntaxes? 

		3. Clients are stupid and untrustworthy and will always lag
years behind
		the state of the art. You can do XSLT on the server side.
I'm not aware of
		any packages for applying CSS or positing elements with
javascript on the
		server side. Plus I hate having to kludge together
client-specific
		javascript to accomodate differing implementations over
which I have no
		control - it's ugly, dangerous, and not maintainable.

		4. XSLT is a beautiful language. CSS+javascript isn't. (big
IMHO of
		course)

		Note that the articles tend to confuse XSLT and XSL:FO,
which is only to
		be expected since they used to be stuck together. I think
XSLT is the
		deal, but I don't understand or particularly like XSL:FO.

		- donald

Mime
View raw message