Thank you, Mike.
It is rare to see such a deep analysis on this topic -- I hope it will find
its place in the XSLT FAQ.
Apart from purely stylistic reasons, I have found one case where the XSLT
style simply cannot be transformed completely into the non-xml style. This
happens, when we need to define and use variables, whose value is a
sequence.
The variables that can be defined in an XPath expression are of the form:
for $someVar in $XPathExpression return
and it works when we need a variable with atomic value.
However, it is not possible using the above syntax to define a variable,
whose value is a sequence.
Thus, if I would need to have my code in a single XPath expression, I would
have to write:
<xsl:sequence select=
"f:scanIter($arg1 - 1, $arg2, $arg3)
,
f:apply($arg2, f:scanIter($arg1 - 1, $arg2, $arg3)[last()])"
/>
because f:scanIter() returns a sequence and it is impossible to write:
"for $vIterMinus in f:scanIter($arg1 - 1, $arg2, $arg3) return
$vIterMinus, f:apply($arg2, $vIterMinus[last()])"
But writing the first expression above will cause
f:scanIter($arg1 - 1, $arg2, $arg3)
to be calculated twice.
Therefore, the more efficient way to express this is using XSLT-style:
<xsl:variable name="vIterMinus"
select="f:scanIter($arg1 - 1, $arg2, $arg3)"/>
<xsl:sequence select=
"$vIterMinus, f:apply($arg2, $vIterMinus[last()])"/>
Thank you once again for this nice discussion.
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
"Michael Kay" <mhk(_at_)mhk(_dot_)me(_dot_)uk> wrote in message
news:000001c39018$87901f10$6401a8c0(_at_)pcukmka(_dot_)(_dot_)(_dot_)
I understand this as personal preference or is this
preference based on some objective criteria?
It's based on instinctive judgements about the engineering quality of
the code, but it's far too early to judge whether my instincts are
right.
I would appreciate your opinion on how do these two styles --
long (20-line
+) XPath expressions versus xslt-structured style -- score in
+readability,
compactness, flexibility, efficiency and maintainability.
There has been an ongoing debate about the merits of using XML syntax
versus non-XML syntax for a while now, and I don't think it's going to
go away. It promises to be one of these perennials like "elements vs
attributes".
Some people seem to take an instinctive dislike to having attributes in
an XML document whose content is 20 lines long. Part of the rationale is
that the newlines don't survive XML parsing, but the newlines are
essential to the readability of the code.
I think it's going to be quite unusual to see XQuery parsers that report
more than one syntax error in a single compile run. The grammar is not
robust enough to allow easy recovery from syntax errors, though the
introduction of semicolons as separators in the latest draft helps.
Reporting multiple errors in XSLT is easy because of the 3-phase parsing
approach (XML parsing first, then XSLT, then XPath). This gives a
definite advantage when you're doing something on the DocBook scale.
In other words, why should we prefer the "XSLT style" to the
"XQuery style"?
I think the advantages of an XML-based syntax are:
(a) it's useful where the stylesheet includes large chunks of stuff to
copy into the result document
(b) it's useful when you want to transform stylesheets or to do any kind
of reflection or introspection
(c) it reuses all the XML machinery such as character encodings, base
URIs, entity references
(d) it's much easier to provide user or vendor extensions to the
language in a controlled way.
But there's no doubt that the XQuery style makes it much easier to write
short queries.
Michael Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list