The Working Group has adopted this change.

Re-opening to request clarification of exactly what change was adopted (if, indeed, decisions were made).

The construct EnclosedExpr is used for two things: embedded content in element/attribute constructors, and for the body of user-defined functions (both named functions and inline functions). Presumably, though I don't see it recorded here, the effect of omitting the expression in these cases will be equivalent to writing {()}, that is, the value of the enclosed expression is taken as an empty sequence (which in the case of a function body results in a type error if an empty sequence is not a valid result).

However, the XQuery spec also uses the term "enclosed expression", sometimes to mean an EnclosedExpr, and sometimes to refer to other constructs that use an expression within curly braces, for example in

element {N} {C}

neither N nor C is grammatically an EnclosedExpr, but both are sometimes referred to in prose as "enclosed expressions". (In this case N is a mandatory expression, while C is an optional expression). (Section 3.9.3.1: "The first enclosed expression after the element keyword generates the name of the element, and the second enclosed expression generates the content and attributes")

Generally, when the term "enclosed expression" is used, it refers to the expression between the curly braces, whereas the term EnclosedExpr includes the delimiting curly braces. So we have the situation that the enclosed expression within an EnclosedExpr may be absent, whereas much of the prose for direct element constructors assumes that the two terms are synonyms.

There are other places where we use an expression between curly braces, for example in a "validate expression", and I assume these are unaffected by this proposal, since we don't describe this as an "EnclosedExpr" in the grammar, or as an "enclosed expression" in the prose.

I think (unless the WG agreed otherwise - I wasn't present):

* When talking about function bodies, we should make it clear that if there is no expression in the EnclosedExpr making up the function body, the effect is equivalent to a function body of "{()}.

* When talking about direct element constructors, in particular where we attempt to define the term "enclosed expression" in 3.9.1 ("In a direct element constructor, curly braces { } delimit enclosed expressions...") we should make it clear that when an EnclosedExpr contains no expression, the effective enclosed expression is "()".

* We should avoid using the term "enclosed expression" in contexts other than an EnclosedExpr. Examples are:

** First para of 3.9 "computed constructors, which use a notation based on enclosed expressions."

** 3.9.3.1 "The first enclosed expression after the element keyword generates the name of the element, and the second enclosed expression generates the content and attributes"

** Same section "the enclosed expression that computes the element name"

* In 3.9.1.1, the sentence "Each enclosed expression is converted to a string as follows" should be "The value of each enclosed expression is converted to a string as follows".

> Presumably, though I don't see it recorded here, the effect of omitting the expression in these cases will be equivalent to writing {()}

I think so.  At least this is what I assumed.  

> "enclosed expression", sometimes to mean an EnclosedExpr, and sometimes to refer to other constructs that use an expression within curly braces

I don't think this makes the decision ambiguous since it was based on the productions listed in Comment 0.  i.e. this seems like more of an editorial problem.  But in any case, I agree with everything in Comment 2.  Thanks for fleshing this out.

Resolved in today's meeting (see minutes).