It's worth reminding people of the benefits of using an XML-based syntax (which
is not to deny that there are drawbacks too):
* you only have one syntax to remember, not two
* editing tools are reusable (I like the fact that CMD+E in oXygen works the
same way for XML and for XSLT)
* stylesheets can be created and transformed using other stylesheets (and other
XML tooling, even XQuery)
* fill-in-the-blanks coding: the stylesheet looks like the output it is
generating
* syntactic extensibility: users, vendors, and the WGs find it easy to add
syntactic extensions without breaking anything or creating ambiguities
Anyone who has watched the Query WG struggle with how to add innocuous features
to the language without breaking the parser will appreciate the last of these.
Historically, of course, the decision was made because of a widespread
consensus that DSSSL failed because it used an unfamiliar syntax that was
radically different from the instance document syntax.
Michael Kay
Saxonica
On 3 Apr 2014, at 16:00, Wendell Piez <wapiez(_at_)wendellpiez(_dot_)com> wrote:
Mike S,
On Mon, Mar 31, 2014 at 9:49 PM, Michael Sokolov
<msokolov(_at_)safaribooksonline(_dot_)com> wrote:
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*.
Understood; nor do I mind XQuery or other syntax that takes this approach.
I also understand why you (or anyone) may take this remark as post-hoc
justification. However, it's not *intended* that way (at least if I am
in a position to judge my own intentions) so much as an observation
bearing on why XSLT's XML syntax doesn't bother some of us as much as
others might think it should.
Cheers, Wendell
--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--