After working exclusively with XSLT for rendering while using XQuery for
search and other tasks, we tried to give the recursive-descent xquery a
whirl for rendering a highly complex schema. It seems to work well, and I
think maintenance will be pretty straightforward, although there's not much
history to judge from yet.
I suppose we will need to improvise to handle things we would do in XSLT as
modes and so on, but given functions with arbitrary arguments, I'm sure we can
come up with something reasonable.
One trick we like is to name all the rendering functions the same, and
distinguish by overloading the arguments, so we don't even really need a
typeswitch: it's built in to the language; just call format($node) on any kind
of node and the right function gets called:
function format ($nodes as node()*) {
for $node in $nodes return format ($node)
}
function format ($text as text()) {
return $text
}
function format ($node as element(foo)) {
(: do special stuff for <foo>, calling format() to recurse when necessary
:)
}
etc...
Of course adding other arguments (like mode or options of some sort) will
complicate this somewhat, but it seems like a good base to start from.
-Mike
>
> On Thu, 28 Aug 2008, Robert Koberg wrote:
>
> > Interesting and well said.
> >
> > I don't suppose your XQuery is something that can be shared
> publicly?
>
> No, but below in a nutshell is the basic strategy. There are two basic
> functions: rend:main(), which would be called on the
> outermost node you need to process (it could be a document
> node, a root element, whatever), containing all the
> typeswitches; and rend:recurse(), that is mostly just a way
> to let you say
>
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
