[Monetdb-developers] New vs. Existing Update Syntax
Hi MonetDB/XQuery folks, I'm in the midst of implementing the support for the "official" XQuery Update Facility syntax. So far it looks like the current code is pretty good in line with the W3C draft. The update operations in the draft are very similar to the update functions we currently have. A few questions, however, appeared when implementing the new syntax: -- It seems to me like we do not (yet) have a rename() function that only changes the tag name of a given element, attribute, or processing-instruction node. -- It is not clear to me how our current insert-...() functions handle attributes in the new node list. 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. Unfortunately, this translation (the split-up of attributes and the rest in particular) is non-trivial in XQuery Core. So we could--in line with the current implementation of element construction--push this treatment of attributes into the back-end. Any comments on this? How does the current code deal with attributes in the arguments of insert-...()? So far for now, Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 XQuery processing at the speed of light: MonetDB/XQuery http://www.monetdb-xquery.org/ http://www.pathfinder-xquery.org/
Jens Teubner wrote:
Hi MonetDB/XQuery folks,
I'm in the midst of implementing the support for the "official" XQuery Update Facility syntax. So far it looks like the current code is pretty good in line with the W3C draft. The update operations in the draft are very similar to the update functions we currently have. A few questions, however, appeared when implementing the new syntax:
-- It seems to me like we do not (yet) have a rename() function that only changes the tag name of a given element, attribute, or processing-instruction node.
That's correct, we don't have such a function.
-- 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.
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)?
Unfortunately, this translation (the split-up of attributes and the rest in particular) is non-trivial in XQuery Core. So we could--in line with the current implementation of element construction--push this treatment of attributes into the back-end.
Any comments on this? How does the current code deal with attributes in the arguments of insert-...()?
They're inserted.
So far for now,
Jens
-- Sjoerd Mullender
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?
Jens Teubner wrote:
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.)
I didn't even know that you could have attribute nodes like this. I guess that answers the question. The insert-* functions were written with the assumption that the to-be-inserted node is an element/comment/pi/text node. It doesn't do anything else, and I relied on the type system to not give me anything else. Aparently that is incorrect. So perhaps the type needs to be changed (if an appropriate type exists) or the function has to do more checking.
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
That is the original document above? Do I understand from this example that the do insert statement can insert multiple nodes in one go?
<?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().
We could perhaps simply select out the attributes from the argument list? They should be easy enough to recognize from the kind column. Or maybe I could add the functionality to our implementation. I will have to see how hard that is. -- Sjoerd Mullender
participants (2)
-
Jens Teubner -
Sjoerd Mullender