Re: [xsl] xsl compact syntax using xquery

Subject: Re: [xsl] xsl compact syntax using xquery
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxx>
Date: Mon, 31 Mar 2014 11:01:05 -0400

On Sun, Mar 30, 2014 at 12:18 PM, Graydon <graydon@xxxxxxxxx> wrote:
>> I'm idly contemplating trying to hatch a proof-of-concept of some
>> sort.  I'm counting on the wisdom of this list to deter me from
>> wasting my time on a terrible idea.  On the other hand perhaps it is
>> a great idea and somebody else will be inspired to implement it,
>> saving me the trouble :) What do you think?
> Expressing XSLT in its data structure is odd, but I think inspired.  It
> makes the requirement to comprehend XML as a structure of nodes
> explicit.  In practical terms, it means that XSLT can, let's say
> comfortably, generate XSLT, and this is very valuable; you can, for
> example, generate transforms on the basis of compact inputs derived from
> specific data.
> I really don't see any positive value in a syntax that would make either
> of those things more difficult.  I also don't see the XSLT syntax as
> problematic.  (This may be one of those things like XML validation; many
> people encounter XML validation as that thing that tells them they're
> doing it wrong, rather than a helpful set of constraints that renders
> your results predictable.)

I agree with Graydon about this: I think XSLT's XML syntax, bizarre as
it is, has some real strengths not evident to newbies or even to us
old folks. Nor is it just being able to generate stylesheets through
your XML serializer, which I see as a fringe benefit. It's more the
first thing, in they way that XML is fully at home in XSLT and

I also find it interesting how many of these alternative approaches
have been defined and partly-mostly implemented -- Tony posted a list
a few days ago -- and yet none of them have ever really caught on.
That suggests several things to me about why this idea may be more
problematic than the initial Aha burst will allow.

I like to tell dot-and-curly-brace fans that XSLT syntax ends up as a
kind of "syntax coloring" for experienced users. We don't read the
tags any more: we can tell what's happening from scanning the match
patterns, select expressions, LREs, modes and a few other things; and
it turns out the verbosity of the XSLT tag set is weirdly conducive to
this kind of "in your head" compiling. Indeed, this verbosity may be
more apparent than real, since while XSLT claims screen space, the
list of possible elements in XSLT is actually quite short -- with the
result that for an experienced user, @match, @select and LREs really
jump out.

(Read a stylesheet whose author has elected not to use LREs but
xsl:element instead, and you get a sense of what I mean. It's just a
little harder to comprehend in a simple scan.)

Yet at the same time, I think it's more or less evident that for at
least some newcomers to the language, a short/sweet syntax would allay
fears and suspicions. But maybe this should explicitly be designed as
a "training wheels" syntax rather than aimed at power users. In that
case, it wouldn't have to support the whole language.

In the meantime, if you take the floor at Balisage and announce that
you have a new concise syntax for XSLT, three people in the audience
will jump up and ask why you aren't using theirs. :-)

Cheers, Wendell

Wendell Piez |
XML | XSLT | electronic publishing
Eat Your Vegetables

Current Thread