xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved...@chebucto.ns.ca
Subject Re: XSL, why another language?
Date Wed, 11 Oct 2000 21:06:22 GMT
Quoting =?iso-8859-1?Q?Ren=E9_Olsthoorn?= <rol@mediasys.nl>:

> Dear reader,
> 
> RenderX has a nice XSL sheet, which is capable of creating a =
> chess-board FO
> file from a XML file which contains some chess-moves.
> You can see the stylesheet at:
> http://www.renderx.com/Tests/chess/chess.xsl
> 
> However, when reading this stylesheet, I noticed that XSL is just =
> trying to
> do programming constructs:
> 
> Extraction:
> 
> - <xsl:choose>
> - <xsl:when test=3D"$move =3D 'O-O'">
> - <xsl:variable name=3D"y">
> - <xsl:choose>
>   <xsl:when test=3D"$player =3D 'white'">1</xsl:when>=20
>   <xsl:otherwise>8</xsl:otherwise>=20
>   </xsl:choose>
>   </xsl:variable>
> - <xsl:variable name=3D"result">
> - <xsl:call-template name=3D"move-piece">
>   <xsl:variable name=3D"from" =
> select=3D"(substring(substring-before($coords,
> '-'), 2, 1) - 1) * 8 + string-length(substring-before('abcdefgh',
> substring(substring-before($coords, '-'), 1, 1))) + 1" />=20
> 
> This is really ugly! It takes us back in time!
> Why don't we figure out a nice Java API, which can do the =
> XSL-translation?
> And forget about the current XSLT syntax?
> 
> Greets,
> Ren=E9 Olsthoorn.
> ROL@europe.com

In a very real sense we already have the API: DOM (Document Object Model), and 
you can use implementations of DOM in any number of languages, including Java 
(and as Dave Pawson pointed out, let's not equate XML and Java - not all of us 
are head-over-heels about Java). That's the other way of converting a source 
XML into a desired result XML (FO's or otherwise), after XSLT (or before, 
depending on what enthusiast you talk to).

The above XSLT example, as Nikolai Grigoriev mentioned, is arguably an extreme 
case. I think who chooses to use which approach is very much a mindset thing - 
XSLT falls into the "if you see this pattern, then do this thing" category, 
just as if you were writing a grammar for a yacc parser, and you are either 
comfortable with that approach to programming, or you're not. It's not 
procedural at all.

I'd be hard pressed to say exactly why I, personally, don't much like DOM. It 
gets the job done, and many people like it. I find it a hard slog, and if I 
want to convert XML form A into XML form B, I find myself arriving at a result 
much faster with XSLT than I do with DOM. But I'm sure that's reversed for 
other folks.

So, to reiterate, if you yourself are not overly enthused with XSLT for XML 
transformations, which is no crime, the alternative already exists. No need to 
reinvent the wheel.

Incidentally, you can't criticize XSLT for containing programming constructs. 
It _is_ a programming language of sorts, after all. :-) And since I do a _lot_ 
of Java collections stuff in real life, let me offer my biased opinion that the 
_Java_ syntax for doing coding of this nature is pretty tortuous, also. :-) 
After a few days of writing Java I find myself writing the equivalent of 20 or 
25 lines of Java in 2 or 3 lines of Perl just to regain some sanity. :-) And 
quite frankly, Java text processing sucks. Just my humble opinion.

Arved Sandstrom


---------------------------------------------------------------
 This mail was sent through the Nova Scotia Provincial Server, 
 with technical resources provided by Chebucto Community Net.
 http://nsaccess.ns.ca/mail/         http://www.chebucto.ns.ca/


Mime
View raw message