On Thu, May 18, 2006 at 12:29:30PM +0200, Sjoerd Mullender wrote:
-- It is not clear to me how our current insert-...() functions handle attributes in the new node list.
The new nodes may contain attributes. They are inserted with the new nodes.
Just to be sure we don't misunderstand each others: I was talking about attribute nodes in the argument to the insert-...() functions, _not_ about attributes that belong to some element in the function argument. I.e., given the document foo.xml: <?xml version='1.0'?> <x> <y/> </x> , will the statement insert-first (doc("foo.xml")/x, attribute foo { 42 }) enrich the root node of the document with a new attribute, resulting in <?xml version='1.0'?> <x foo="42"> <y/> </x> , On the system I tested this situation led to weird MIL errors only. (Note that the insert function are declared as `fn:insert-first (node, node)', etc. So they should accept all node kinds in both arguments.)
The W3C draft provides separate upd:insertAttributes ($element, $attlist) and upd:insertBefore ($element, $nodelist) functions (and similar). The translation from the surface syntax to the update operations then takes care of invoking the right functions.
Is upd:insertAttributes similar to our set-attribute function (except that set-attribute works on a single attribute)?
Yes, I think so. But this is not actually the problem we have. I will try to illustrate the problem. The query do insert (attribute foo { 42 }, element bar { 17 }) as first into fn:doc ("foo.xml")/x should modify the above mentioned XML document to <?xml version='1.0'?> <x foo="42"> <bar>42</bar> <y/> </x> . So the "SourceExpr" for the `do insert' statement is allowed to contain attributes as well as other node kinds. The specs then say that we have to add the attributes using upd:insertAttributes(), the rest via upd:insertBefore(). We do have both update functions. What do _not_ have is a means to _separate_ the attributes from the remaining node kinds in XQuery Core. This is why I was asking if our implementation of the insert-...() function can cope with attributes. If that was the case, we would not need upd:insertAttributes() at all for this situation and handle everything in upd:insertBefore()/fn:insert-before(). Regards, Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Real programmers don't comment their code. If it was hard to write, why should it be easy to read?