is it just me?

["Mark D. Anderson" <mda@xxxxxxxxxxxxxx>]

ok, i finally sat down and started an xsl app today,
the xsl spec in one screen and my editor in the other.

the processing model seems sufficient; i haven't gotten
enough deep into it to say whether it is powerful enough.

but the syntax? i must admit that a few months ago (without
actually trying xsl), i thought it was a natural requirement
to say that xsl has to be in xml syntax. but now that i've
typed something of this form:

<xsl:when>
 <xsl:choose> ... </xsl:choose>
 <xsl:other> ... </xsl:other>
</xsl:when>

i'm having second thoughts.

the whole time i'm reading the spec, i'm thinking things like
"xsl:constant, ok, a constant.... xsl:macro, ok, a macro...
xsl:for-each, got it....". and whenever i read xsl code, i
have to mentally map it to mental pseudo-code that is a fraction
of the size.

i know, i know, at some point soon, there will be a story
for an eval escape, and xsl isn't designed to be a programming
language. but even so, the syntax is painful. and i don't
buy the "not designed to be a programming language" argument,
when a significant fraction of the xsl tags are for
programming constructs.

i'm sure that the decision to not use a more natural programming
syntax (let alone using something so fear-inspiring as parens) is
by now irreversible. i note that there is xslj to convert xsl to
dsssl. seems like what i'd really like is something that converts
a dsssl subset to xsl, or a perl subset, or what have you.
that way i could comfortably write my style sheets in a syntax
more comfortable for a programmer, and yet still leverage future
xsl technology -- where most of the tools will be, for good or nought.

anyone have any thoughts on that? maybe a scheme subset that just
has the operators in the xsl namespace....

-mda



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list