Re: [Xmldb-org-xupdate] Poorly defined update instruction

[Ronald B. <rpb...@rp...>]

John L. Clark wrote:

> Well, the spec says that the update operation "can be used to update the
> content of existing nodes".  From the example given, I took this to mean
> that the subtree underneath the selected node was replaced with the
> update operation's content.  This is why I thought that the replacing
> content could be any valid XML content.  If a text node is explicitly
> selected, though, it does not have any subtree to update.
> 
> To be explicit, if your example above were allowed, then following the
> example in the spec, both of:
> 
> ---
> <xupdate:update select="/addresses/address[2]/town"
>   xmlns:xupdate="http://www.xmldb.org/xupdate">New York</xupdate:update>
> ---
> 
> and
> 
> ---
> <xupdate:update select="/addresses/address[2]/town/text()[1]"
>   xmlns:xupdate="http://www.xmldb.org/xupdate">New York</xupdate:update>
> ---
> 
> could be used for the same update.  However, they explicitly select
> different nodes for which to "update the content", which I believe is
> fundamentally broken.  I would argue for one way or the other, but not
> both.  I would prefer that the latter be made normative (that is, that
> update be treated precisely as node replacement, hence my original
> argument about the assignment operator semantics).

I prefer content replacement to node replacement. Node replacement would 
mean that if I selected the node <date>10/11/12</date>, I would have to 
include the <date> markup in my update instruction, which feels 
unnatural when all I want to do is change the date.

This also shows why it would be useful to have an xupdate:replace 
element as Wolfgang suggests. This would allow me to replace the <date> 
element with <birthday>, for example. To my mind, this is very distinct 
from changing a value.

>>3) It would be useful for update to allow element, attribute, etc. as 
>>content. That said, I'm not convinced it's worth the complexity, as you 
>>can simply delete the element and reinsert it with the new content.
> 
> I'm not convinced that it is that complex; it seems quite natural (at
> least to me), and it seems to follow suit with the other XUpdate
> operators.

Now that I've thought about it, I agree.

-- Ron