[Bug 29185] The expression inside curly braces should be optional

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29185

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |mike@saxonica.com
         Resolution|FIXED                       |---

--- Comment #2 from Michael Kay <mike@saxonica.com> ---
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".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 21 October 2015 09:24:52 UTC