On 3/31/14 11:01 AM, Wendell Piez wrote:
Hi,
On Sun, Mar 30, 2014 at 12:18 PM, Graydon <graydon(_at_)marost(_dot_)ca> 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.
Well having a compact syntax wouldn't eliminate the XML syntax, so it
certainly wouldn't prevent anyone from generating and evaluating XSLT
using XSLT, written in whatever form. I guess it's mostly a comfort and
familiarity decision. For example, I like RelaxNG compact: it just
looks right to me. I'm sure this is due to a lifetime spent in C, C++,
Java and JavaScript (and XQuery). Well actually I started with quite a
bit of LISP, too, but I never really got the taste for undifferentiated
data/code soup, as heady as it is. Actually I'm beginning to prefer the
even terser Python/YAML style. For me it really is helpful to have
fewer extraneous characters on the screen. Perhaps it's my worsening
vision -- in younger days I would use tiny fonts and fill my screen with
text, but no more.
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.
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 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.
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*.
(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. :-)
That alone makes it sound worth the effort !
-Mike
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--