[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Are there any free, fully-compliant XSLT/XPath 3.0 processors?

Subject: Re: [xsl] Are there any free, fully-compliant XSLT/XPath 3.0 processors?
From: Graydon <graydon@xxxxxxxxx>
Date: Sun, 27 Jan 2013 22:22:31 -0500

On Sun, Jan 27, 2013 at 03:12:14PM -0500, Michael Sokolov scripsit:
> Am I missing the point?  Is XQuery/XSLT/XPath really an embedded
> capability to be used primarily from within one of these other
> languages?

I think you're missing that it's a hierarchical data query/tree
transformation facility/mechanism to express relationships in a
particular model of trees; it's really not supposed to solve problems
other than dealing with tree models of data as expressed in XML.  (My
sense is that this is because those problems are perceived as being
Plenty Hard Enough.)

I think the core thing to remember is that XML technology --
XSLT/XQuery/XPath --  programmers are (relatively, compared to Java or
PHP or Perl or whichever) rare, expensive, and hard to replace.  This
makes businesses reluctant to become dependent on one or more of them in
the presence of alternatives.

So while I think 2.0 is a huge improvement over 1.0 in terms of
simplicity of expression -- try tokenize($path,'/')[last()] in 1.0
sometime! -- and think 3.0 is going to be a similar improvement -- I am
very much looking forward to being able to write

replace($x,'\p{Zs}+',' ')!replace(.,'+_','_')

instead of

replace(replace($x,'\p{Zs}',' '),'_+','_')

because those replace chains get _long_ sometimes -- and would go so far
as to assert that this is true even when dealing with the weird, hinky,
and counter-intuitive aspects of xsl:for-each-group (because the 1.0
approaches to grouping are _much worse_), I don't think the barriers to
broader XML programming technology adoption have anything much to do
with the already stupidly powerful and trending better technology.

I think it's mostly got to do with a not-indefensible perception that
it's better to do something in the more common way, because that avoids
a whole category of business risk around a (plausibly) better but less
common -- and thus maybe suddenly unavailable -- technology.

I will note that there are classes of problems, notably around
documents expressed in XML and big masses of hierarchical data expressed
in XML, where the "oh basically linewise web tech will do, won't it?"
approach tends to fail spectacularly.  But for most web-ish data
presentation applications, the XML tech set is a bigger hammer than you
actually need.

-- Graydon, who is going to stop before the analogy with regular
expressions becomes irresistible.

Current Thread