Interesting idea, although I'm not sure I like the way you spell the operator "!!". Maybe just using "modify" as an infix operator would be more clear.

Yes, I’m open for alternative spellings.

One way why I chose special characters over a string is that we would need to introduce two keywords (The full-text keyword "contains" was changed to "contains text" for the same reason), and something like "<a/> modify node insert node <b/> into ." isn’t that catchy anymore.

We (or the user) could define a function 

modify($n as node(), $f as updating function($n as node())) {
  copy $m := $n
  modify $f($m)
  return $m
}

and then you could write

for $e in //item[@status ne 'up-to-date']
return element updated { modify($e, function($n) {insert node <sub/> into $n}) }

This would be even more attractive if we had a terser syntax for inline functions. In FtanSkrit I used 

{$1 + $2}

for a function that adds its two arguments (i.e. our "function ($n, $m) {$n + $m}"). We've decided to use a bare "{" for maps, but we could still go with something like {= $1 + $2 }, the leading '=' being familiar to spreadsheet users - or even just a leading '=' without the curlies:

for-each($seq, =($1 + 1))

and then Christian's example becomes

for $e in //item[@status ne 'up-to-date']
return element updated { modify($e, =insert node <sub/> into $1)}

I think we should be trying to build new capability by exploiting higher-order functions wherever we can, in preference to inventing new higher-order operators.

Mike, thanks for the response. I also think that a higher-order approach could offer a comparable solution, provided that the syntax gets more concise at some stage (the FtanSkrit proposal looks compelling). 

As the modification of nodes in main-memory has got a very basic operation, looking at our user feedback and our use cases, and as the effort for specifying and implementing the extension is minimal, I still believe it could deserve its own operator, as the existing solution is just too clumsy. If one single keyword can be used, "modify" may be the better choice?

I noticed that "modify" is no viable alternative, as it would get in conflict with the existing keyword, when being used in the transform expression:

  copy $c := <c/> modify insert node <X/> into $c return $c

Other alternatives for "!!" could be the keyword "update", the special character "~" or "<<" (to indicate that the following expressions have affect the lefthand operand):

  <c/> !! insert node <X/> into .
  <c/> << insert node <X/> into .
  <c/> ~  insert node <X/> into .
  <c/> update insert node <X/> into .

A little addition: we believe that the "update" keyword is the best choice. It is both well readable and connects better to the existing vocabulary of the XQUF:

CURRENTLY:
  for $item in db:open('data')//item
  return copy $c := $item
         modify delete node $c/text()
         return $c

PROPOSED:
  for $item in db:open('data')//item
  return $item update delete node text()

If the 'update' keyword should cause conflicts, and if we want to avoid special characters, 'update node' or 'modify node' would probably be the most consistent choice.

and what about "updated by" ?

...yes, might be more readable. Another alternative (to align the wording with the existing transform expression) could be "modified by":

  doc('input.xml')//item modified by (
    replace node . with element TEXT { text() }
  )

The Working Group agrees. We are adding the following ExprSingle:

TransformExpr ::= PathExpr ("transform" "with" "{" Expr? "}")?

and

SimpleMapExpr ::= TransformExpr ("!" TransformExpr)*

Thanks for looking at this.

One more question: I was surprised about the addition of the curly brace, as we now have three mandatory tokens. Wouldn't one of the following expression be syntactical valid, and sufficient?

  a) <a/> transform with insert node <b/> into .
  b) <a/> transform { insert node <b/> into . }

We need a terminating token for the TransformExpr as the insert expressions are all directly under ExprSingle, which creates ambiguity in operators after the TransformExpr.

I think "$E transform { ... }" would work syntactically.

Fine. In this case, I would prefer to get rid of the additional keyword. What do others think?

At the Face-to-Face in Prague, we decided as following:

DECISION: Adopt the simple TransformExpr as described by bug 23643 and 
modified to use the following syntax:

SimpleMapExpr ::= TransformExpr ("!" TransformExpr)*			
TransformExpr ::= PathExpr ("transform" "with" "{" Expr? "}")?

We apparently forgot to record that decision here.

I just reopened the issue, as there is already a TransformExpr in XQuery 3.0 Update:

[206] TransformExpr ::= "copy" "$" VarName ":=" ExprSingle (","
      "$" VarName ":=" ExprSingle)* "modify" ExprSingle "return" ExprSingle

We could rename the new expression to ModifyExpr or something similar.

Next, I still wonder why/if we really need three tokens..

  "transform" "with" "{"

..or if we could get rid of "with" or "{"? In my initial proposal, I suggested to move the expression within AndExpr and ComparisonExpr; would this help?

(In reply to Christian Gruen from comment #16)
> I just reopened the issue, as there is already a TransformExpr in XQuery 3.0
> Update:
> 
> [206] TransformExpr ::= "copy" "$" VarName ":=" ExprSingle (","
>       "$" VarName ":=" ExprSingle)* "modify" ExprSingle "return" ExprSingle
> 
> We could rename the new expression to ModifyExpr or something similar.

So TransformExpr uses the keyword "modify",
whereas ModifyExpr uses the keyword "transform".

Any chance we could fix that?

(In reply to Michael Dyck from comment #17)

> So TransformExpr uses the keyword "modify",
> whereas ModifyExpr uses the keyword "transform".
> 
> Any chance we could fix that?

The names of nonterminals can be changed without changing the language.  We may need WG approval for this, but I think we should do this.

I've argued in the past for the copy/modify expression to be called something other than TransformExpr (but for some reason, I failed to convince people).

When the name of an expression bears no relationship to the keywords used, it makes it very difficult to construct error messages that will be meaningful to the 95% of users who haven't read the W3C spec.

Maybe the tokens "update" "{" would be a feasible alternative? In that case, we could call the rule UpdateExpr.

The WG discussed this at meeting #585 abd made the following decision:

Rename the current TransformExpr to CopyModifyExpr, and name the nonterminal for the "transform with" expression TransformWithExpr.

I have reopened this bug (sorry for my perseverance):

1. First, I would like to quote John Snelson's concerns, which I share:

> [...] I think the precedence for the transform with expression is wrong.
> I propose we move it to between CastExpr and UnaryExpr, so that it is
> situated along with the other textual operators, and so that a simple map
> expression can occur on it's left hand side without parentheses.

2. I'm still wondering if one or two tokens, such as "transform" "{" (as John proposed in Comment 13), or even simply "transform", would not be sufficient. I had to think of my initial feature request, in which I suggested to move the new expression between AndExpr and ComparisonExpr:

  AndExpr        ::= TransformExpr ( "and" TransformExpr )*
  TransformExpr  ::= TransformExpr ( "transform" ComparisonExpr )?
  ComparisonExpr ::= ...

I am pretty sure I have overseen something, but from the answers given so far I could not explain to myself why...

 a)  X and Y

...is a valid expression whereas it seems that...

 b)  X transform Y

would not be valid. Could someone possibly give me an example that demonstrates the problem? Or does the problem only occur if the TransformExpr is moved further down in the grammar?

The working group reconsidered the syntax of the TransformWithExpr and decided not to make a change to it.