Those are good points. I generally use XQuery as a code generator to
write a skeleton module for large transform libraries (schema migration,
for example). That reduces the burden of starting a project, and gets me
to the "easier to maintain" state more quickly.
Here's an example: this one reads the element names from a schema, and
creates a dummy transform function for every element it finds. If no
schema is found, it still generates the skeleton of a recursive-descent
transform. To use it effectively, personalize the module namespace, the
default element namespace, and the schema location. Note that the
generated code is also saved in /tmp/ on the server.
I'm sure this code could be improved, but perhaps it'll help someone on
the list.
xquery version "0.9-ml"
(: schema no-op builder :)
define variable $NL as xs:string { codepoints-to-string(10) }
define variable $OPTS-SIG as xs:string { '$opts as element(m:options)' }
let $names :=
for $e in doc('myschema.xsd')/xs:schema/xs:element
let $name as xs:string := $e/@name
order by $name
return $name
let $module := (
'xquery version "0.9-ml"',
'(:',
' : lib-noop.xqy',
' :',
' :)',
'module "myproject.noop"', '')
let $decls := (
'default function namespace =
"http://www.w3.org/2003/05/xpath-functions";',
'default element namespace = "my-input-namespace"',
'declare namespace m = "myproject.noop"',
''
)
let $defs :=
for $name in $names
return (
concat('define function m:', $name, '('),
concat(' $n as element(m:', $name, '), ', $OPTS-SIG, ')'),
' as node()*',
'{',
concat(' element ', $name, ' {'),
' $n/@*,',
' m:do($n/node(), $opts)',
' }',
'}', '')
let $do := (
concat('define function m:do($nodes as node()*, ', $OPTS-SIG, ')'),
' as node()*',
'{',
' for $n in $nodes return typeswitch($n)',
for $name in $names
return (
concat(' case element(m:', $name, ')'),
concat(' return m:', $name, '($n, $opts)')
),
' case document-node() return m:do($n/node(), $opts)',
' default return $n',
'}', '',
'(: overload m:do for empty options :)',
concat('define function m:do($nodes as node()*)'),
' as node()*',
'{',
' m:do($nodes, <m:options/>)',
'}'
)
let $main-module := string-join(($decls, $do, $defs, '1'), $NL)
let $eval :=
try { xdmp:eval($main-module) } catch ($ex) { $ex, $main-module }
let $lib-module :=
text { string-join(($module, $decls, $defs, $do), $NL) }
let $save := xdmp:save('/tmp/lib-noop.xqy', $lib-module)
return $lib-module
-- Mike
David Sewell wrote:
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:
* XSLT 2.0 (I avoid working in 1.0 unless there's no choice) is much
more efficient than XQuery for ad-hoc transforms, quick one-time
modifications of one document structure to another, and uncomplicated
"push" transformation of entire documents (XQuery is of course optimized
for "pull" transformations, pulling bits and pieces out of XML files). I
use it daily for work on my filesystem files.
* But it's entirely possible to write a complex recursive rendering with
dozens of element "templates" via XQuery functions, and
* Once you've done it, the XQuery function library is probably easier to
maintain than one or more XSLT files of similar complexity.
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.
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.
DS
On Thu, 28 Aug 2008, Robert Koberg wrote:
On Aug 28, 2008, at 1:43 PM, Jason Hunter wrote:
You may or may not like recursive descent as a style. Our point of view on
the MarkMail team is that XQuery with recursive descent lets us do
everything XSLT would, and it gets the job done really fast.
I am sure that is true for highly structured documents like email. But say you
have complex document schema similar to docbook (or even 25% of its
complexity) and you want to convert that to XHTML, would that still hold true?
Would the XQuery be maintainable?
I'd be curious if there have been discussions and what the results where
regarding incorporating XSL in the MarkLogic DB. Is this something we can look
forward to?
Don't get me wrong, I really like XQuery and think the MarkLogic DB is a great
product. I would like to see it even better!
best,
-Rob
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
