David Sewell <[EMAIL PROTECTED]> writes:
> Well, I can speak as someone one of whose tasks just today has been to
> edit a library file containing about 2000 lines of MarkLogic XQuery code
> to perform all of the recursive XML-to-HTML rendering for the version 2
> of a publication based on quite complex TEI (Text Encoding Initiative)
> XML--definitely comparable to DocBook in complexity.
>
> My brief feedback, based on our several years' experience using ML
> Server, would be:
With a fair bit of XQuery under my belt now and a whole lot of XSLT
(as it turns out, for the XSLT stylesheets for DocBoook :-), I have to
say my perspective remains somewhat different.
> * XSLT 2.0 (I avoid working in 1.0 unless there's no choice) is much
I agree with you there.
> * But it's entirely possible to write a complex recursive rendering with
> dozens of element "templates" via XQuery functions, and
I'll go so far as to agree that it's entirely possible.
> * Once you've done it, the XQuery function library is probably easier to
> maintain than one or more XSLT files of similar complexity.
But I don't think I'll ever be convinced that it's as easy to
maintain.
* Typeswitch only gets you as far as the element name. There are lots
of cases where it's very convenient to divide functionality based on
attributes and other characteristics that are easy to select with
an XSLT match pattern.
* Modes are very convenient for content that needs to be rendered in
different ways. You can fake it with yet more functions, but it's not
pretty.
* Perhaps the most significant feature from a maintenance perspective
is the ability to import an existing stylesheet and override a single
template (or a small number of templates).
Beyond the maintenance issues, there's significant functionality in
XSLT that's not (at least not yet) in XQuery: xsl:for-each-group and
xsl:analyze-string being the first two that spring to mind.
> The reason for the last point is twofold: the cleaner/simpler syntax of
> XQuery, and the fact that functions, sequences, and flow control are
> integrated into the language from the start rather than being to some
> extent tacked on as they are with XSLT.
I don't perceive anything "tacked on" about functions, sequences, or
flow control in XSLT. Well, there's a little redundancy in that XPath
2.0 introduces some flow control mechanisms that already existed in
XSLT.
> That said, I'd be pleased if an XSLT parser were eventually bundled into
> MarkLogic Server (and I've said this at least once a year for the last
> four years or so), just because it would provide more flexibility, and
> because I don't see either language withering away anytime soon.
I'm pushing as hard as I can, believe you me :-)
Be seeing you,
norm
P.S. I suppose I should say explicitly in this context that the
opinions above are purely my own. :-)
--
Norman Walsh
Principal Technologist
Mark Logic Corporation
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
