On Wed, Nov 25, 2020 at 04:56:06AM -0000, Dimitre Novatchev
dnovatchev(_at_)gmail(_dot_)com scripsit:
works, but while this is doubtless a question of aesthetic bias I don't
consider this solution more elegant than (or preferable to) the XSLT version
[snip]
*As for elegance*, one can write a more elegant expression if one defines a
separate inline XPath function:
*let $makeElement := function($k, $v) {*
* parse-xml('<' || $k '>' || $v '</' || $k '>' )*
* return*
* ($wordArchive ! $ makeElement('entry', map:for-each(., $makeElement
($k, $x)))*
* ! parse-xml(.)*
*}*
This is still constructing the serialized form as a string, which gives me the
flinch. Experience says this is not how I lower the maintenance cost of the
code.
Not to mention that having a comprehensive library of XPath functions is
both powerful and elegant as it provides a set of basic building blocks for
potentially unlimited number and scope of problems.
I think having actual node constructors in XPath would be helpful. Having my
own XPath function library introduces all sorts of maintenance and portability
problems customers are generally savvy enough to spot and complain about. (and
my employer is _certainly_ savvy enough to spot and complain about!)
--
Graydon Saunders | graydonish(_at_)gmail(_dot_)com
Þæs oferéode, ðisses swá mæg.
-- Deor ("That passed, so may this.")
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--