Subject: Re: [xsl] xsl compact syntax using xquery|
From: Michael Sokolov <msokolov@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 31 Mar 2014 21:49:26 -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 vice-versa.
Yes, this and the existence of other recent examples does make the whole enterprise sound much less appealing. The territory turns out to be full of muddy criss-crossing tracks, each trodden once or twice.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 hear you, but it sounds to me like a post-hoc justification. I really think I prefer the coloring to be stronger: I'd like the LRE's to look like XML and the rest to look like *code*.
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.
That alone makes it sound worth the effort !
(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. :-)