[Monetdb-developers] New vs. Existing Update Syntax

Sjoerd Mullender sjoerd at acm.org
Thu May 18 16:03:42 CEST 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://www.monetdb.org/pipermail/developers-list/attachments/20060518/f1b944b6/attachment.sig>


More information about the developers-list mailing list