On Mon, 15 Sep 2008 12:44:47 -0700, Eric Palmitesta
<[EMAIL PROTECTED]> wrote:
Hey Mary, this seems fundamentally important, can you elaborate?
(For example why x$/node() rather than $x/child::*)
Eric
Because $x/node() matches all child nodes, be there text, element,
comments,
or processing instructions, whereas $x/child::* only selects elements.
This is because wildcard tests only match against the "principal node
kind" of the axis. In the case of child:: this is element. So the
query as written with $x/text(), $x/child::* means: take all the text
content of the node, put it up front, then follow it by all the elements.
So:
<scramble>Here<!-- with a comment --> is a <b>simple</b>
example</scramble>
would come out of function g as:
<scamble new="new">Here is a example<b>simple</b></scramble>
//Mary
Mary Holstege wrote:
On Mon, 15 Sep 2008 10:55:08 -0700, Florent Georges
<[EMAIL PROTECTED]> wrote:
Eric Palmitesta wrote:
Hi
It works. Is there a better way though? Also, what's the
point of xdmp:node-insert-child if it can't operate on an
argument to a function?
Yes it can, but not on constructed nodes. You can make a bit
more generic:
define function g($x as element()) as element()
{
element { node-name($x) } {
$x/text(),
$x/child::*,
$x/attribute::*,
attribute new{ "new" }
}
}
Actually, you need to be a little careful here.
Attributes should come first, and the query above will reorder
text children relative to your element children. What you want is:
element {node-name($x)} {
$x/@*,
attribute new {"new"},
$x/node()
}
//Mary
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
