Re: XQuery Updates in XSLT

On Wed, Oct 29, 2008 at 1:01 PM, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:
> Hi,
>
> At 03:48 PM 10/29/2008, it was written:
>>
>> Yes. It's a few lines of easily readable XQuery Update, versus a few
>> complete XSLT templates and an explanation of how the identity transform
>> works.
>
> This is sort of funny. Kind of like "it's a few lines of easily readable
> Japanese, versus a few English sentences and an explanation of English
> grammar."
>
> There are millions of people to whom this is entirely sensible as a high
> recommendation, just as there are certainly many to whom the other claim
> makes sense.
>
> And mind you, I *like* XQuery. I just don't think it's inherently easier.
> Apparently, neither do XQuery companies, who (I hear) are eager to find
> developers who are already conversant with XPath and don't expect XQuery
> over XML to work just like SQL over RDBMS. These are frequently people who
> have XSLT experience.

Let's leave aside the question whether XQuery Update Facility 1.0 is a
functional language or not (this is not immediately clear from the
Candidate Recommendation, although the document states that there are
operations ("Update Operations") that "although these update
operations are described using a functional notation, they are not
true functions because many of them have no return value.").

When I said:

> Such a feature will be the killer of a nice, functional language, I agree... :)

the emphasis was on the word "nice".

Thanks to the contributors of this thread, which I enjoyed very much.
This prompted me to read the XQuery Update Facility 1.0 Candidate
Recommendation and the immediate ner result is that personally I feel
rather uninspired to use such a language. My first reaction is that if
I must choose between XQuery Update and DOM I would stick with the
latter, no matter how much I naturally try to avoid using DOM.

The spec is too complex and presents definite challenge for
understanding. To illustrate this, here is how the "insert operation"
is defined:

"The semantics of an insert expression are as follows:
1.	SourceExpr must be a simple expression; otherwise a static error is
raised [err:XUST0001]. SourceExpr is evaluated as though it were an
enclosed expression in an element constructor (see Rule 1e in Section
3.7.1.3 ContentXQ). The result of this step is either an error or a
sequence of nodes to be inserted, called the insertion sequence. If
the insertion sequence contains a document node, the document node is
replaced in the insertion sequence by its children. If the insertion
sequence contains an attribute node following a node that is not an
attribute node, a type error is raised [err:XUTY0004]. Let $alist be
the sequence of attribute nodes in the insertion sequence. Let $clist
be the remainder of the insertion sequence, in its original order.
Note:
Either $alist or $clist or both may be empty.
2.	The target expression must be a simple expression; otherwise a
static error is raised [err:XUST0001]. The target expression is
evaluated and checked as follows:
a.	If the result is an empty sequence, [err:XUDY0027] is raised.
b.	If any form of into is specified, the result must be a single
element or document node; any other non-empty result raises a type
error [err:XUTY0005].
c.	If before or after is specified, the result must be a single
element, text, comment, or processing instruction node; any other
non-empty result raises a type error [err:XUTY0006].
d.	If before or after is specified, the node returned by the target
expression must have a non-empty parent property [err:XUDY0029].
Let $target be the node returned by the target expression.
3.	If $alist is not empty and any form of into is specified, the
following checks are performed:
a.	$target must be an element node [err:XUTY0022].
b.	No attribute node in $alist may have a QName whose implied
namespace binding conflicts with a namespace binding in the
"namespaces" property of $target [err:XUDY0023].
c.	Multiple attribute nodes in $alist may not have QNames whose
implied namespace bindings conflict with each other [err:XUDY0024].
4.	If $alist is not empty and before or after is specified, the
following checks are performed:
a.	parent($target) must be an element node [err:XUDY0030].
b.	No attribute node in $alist may have a QName whose implied
namespace binding conflicts with a namespace binding in the
"namespaces" property of parent($target) [err:XUDY0023].
c.	Multiple attribute nodes in $alist may not have QNames whose
implied namespace bindings conflict with each other [err:XUDY0024].
5.	The result of the insert expression is an empty XDM instance and a
pending update list constructed as follows:
a.	If as first into is specified, the pending update list consists of
the following update primitives:
i.	If $alist is not empty, upd:insertAttributes($target, $alist)
ii.	If $clist is not empty, upd:insertIntoAsFirst($target, $clist)
b.	If as last into is specified, the pending update list consists of
the following update primitives:
i.	If $alist is not empty, upd:insertAttributes($target, $alist)
ii.	If $clist is not empty, upd:insertIntoAsLast($target, $clist)
c.	If into is specified with neither as first nor as last, the pending
update list consists of the following update primitives:
i.	If $alist is not empty, upd:insertAttributes($target, $alist)
ii.	If $clist is not empty, upd:insertInto($target, $clist)
d.	If before is specified, let $parent be the parent node of $target.
The pending update list consists of the following update primitives:
i.	If $alist is not empty, upd:insertAttributes($parent, $alist)
ii.	If $clist is not empty, upd:insertBefore($target, $clist)
e.	If after is specified, let $parent be the parent node of $target.
The pending update list consists of the following update primitives:
i.	If $alist is not empty, upd:insertAttributes($parent, $alist)
ii.	If $clist is not empty, upd:insertAfter($target, $clist)"





Here is another operation definition:




"3.2.2 upd:applyUpdates
Parameters
upd:applyUpdates(
   $pul as pending-update-list,
   $revalidation-mode as xs:string)
Summary
This routine ends a snapshot by making effective the semantics of all
the update primitives on a pending update list and by revalidating the
resulting XDM instance.
Constraints
$revalidation-mode must be "strict", "lax", or "skip"
Semantics
1.	Checks the update primitives on $pul for compatibility. Raises a
dynamic error if any of the following conditions are detected:
a.	Two or more upd:rename primitives on $pul have the same target node
[err:XUDY0015].
b.	Two or more upd:replaceNode primitives on $pul have the same target
node [err:XUDY0016].
c.	Two or more upd:replaceValue primitives on $pul have the same
target node [err:XUDY0017].
d.	Two or more upd:replaceElementContent primitives on $pul have the
same target node [err:XUDY0017].
e.	Two or more upd:put primitives on the merged list have the same
$uri operand [err:XUDY0031].
f.	Two or more primitives on $pul create conflicting namespace
bindings for the same element node [err:XUDY0024]. The following kinds
of primitives create namespace bindings:
i.	upd:insertAttributes creates one namespace binding on the $target
element corresponding to the implied namespace binding of the name of
each attribute node in $content.
ii.	upd:replaceNode creates one namespace binding on the $target
element corresponding to the implied namespace binding of the name of
each attribute node in $replacement.
iii.	upd:rename creates a namespace binding on $target, or on the
parent (if any) of $target if $target is an attribute node,
corresponding to the implied namespace binding of $newName.
2.	The semantics of all update primitives on $pul, other than upd:put
primitives, are made effective in the following order:
a.	First, all upd:insertInto, upd:insertAttributes, upd:replaceValue,
and upd:rename primitives are applied.
b.	Next, all upd:insertBefore, upd:insertAfter, upd:insertIntoAsFirst,
and upd:insertIntoAsLast primitives are applied.
c.	Next, all upd:replaceNode primitives are applied.
d.	Next, all upd:replaceElementContent primitives are applied.
e.	Next, all upd:delete primitives are applied.
3.	If, as a net result of the above steps, the children property of
some node contains adjacent text nodes, these adjacent text nodes are
merged into a single text node. The string-value of the resulting text
node is the concatenated string-values of the adjacent text nodes,
with no intervening space added. The node identity of the resulting
text node is implementation-dependent.
4.	If, as a net result of the above steps, the children property of
some node contains an empty text node, that empty text node is deleted
from the children property.
5.	If the resulting XDM instance violates any constraint specified in
[XQuery/XPath Data Model (XDM)], a dynamic error is raised
[err:XUDY0021].
Note:
For example, a data model constraint violation might occur if multiple
attributes with the same parent have the same qualified name (see
Section 6.2.1 OverviewDM.)
Note:
During processing of a pending update list, an XDM instance may
temporarily violate a data model constraint. An error is raised only
if a constraint remains unsatisfied after all update primitives other
than upd:put have been applied.
6.	For each document or element node $top that was marked for
revalidation by one of the earlier steps, upd:revalidate($top,
$revalidation-mode) is invoked.
7.	As the final step, all upd:put primitives on $pul are applied.
8.	The upd:applyUpdates operation is atomic with respect to the data
model. In other words, if upd:applyUpdates terminates normally, the
resulting XDM instance reflects the result of all update primitives;
but if upd:applyUpdates raises an error, the resulting XDM instance
reflects no changes. Atomicity is guaranteed only with respect to
operations on XDM instances, and only with respect to error conditions
specified in this document.
Note:
The results of implementation-dependent error conditions such as
exceeding resource limits are beyond the scope of this specification.
9.	Propagation of XDM changes to an underlying persistent store is
beyond the scope of this specification. For example, the effect on
persistent storage of deleting a node that has no parent is beyond the
scope of this specification"




This overwhelming complexity makes it very challenging to even get an
idea about the language. It also puts an obvious, instinctive doubt in
the logical soundness and correctness of the system being described.

Decide for yourselves how much you would like to invest in trying to
comprehend such a document in order to use the language it describes.

I have made my own, personal decision, and this was an easy to make.
Please, note that I am intentionally avoiding the discussion of such
relevant topics as aesthetics and ugliness, as these are always vastly
personal and not always having a direct and visible connection to the
rational. Therefore, I do not express any surprise at the fact that
there may be some people, who would find XQuery Update more elegant
than XSLT. As always, there are people, who like their Segways, and
there are those, who like their huge MACK trucks.


-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play