or one can do:
<xsl:value-of separator="" select="
for $a in 65 to 90 return
for $b in $a to 90 return
codepoint-to-string($a), codepoint-to-string($b)" />
Clearly less a higher signal-to-noise ratio if you do it this
way rather than lots of xsl elements.
Yes: but remember that redundancy isn't all bad. A certain level of
redundancy makes code easier to read, and it certainly makes it easier for
the compiler to report errors intelligently and recover from them. One of
the weaknesses of the XQuery syntax is that error recovery (needed to report
more than one syntax error in a single run) is very difficult. Another big
benefit of the XML-based syntax is extensibility - adding new constructs is
vastly easier for XSLT than for XQuery, which is one reason why XSLT has
things like analyze-string that XQuery is lacking.
Isn't the problem all about how to escape between literal
result elements and XPath statements?
Doesn't XQuery address that with use of curly brackets .. at
least from lit elements into XPath though not back again?
Yes, XQuery has stronger composability, because you can nest constructs more
freely. But the curly braces create problems of their own. On another list,
there's a discussion going on about why the result of <a>{<b/>}</a> isn't
always the same as <a><b/></a>. As you might expect, it's all to do with
namespaces.
Michael Kay
http://www.saxonica.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>
--~--