This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29185 - The expression inside curly braces should be optional
Summary: The expression inside curly braces should be optional
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.1 (show other bugs)
Version: Proposed Edited Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-08 14:47 UTC by Josh Spiegel
Modified: 2015-10-27 16:51 UTC (History)
1 user (show)

See Also:


Attachments

Description Josh Spiegel 2015-10-08 14:47:37 UTC
See:
https://lists.w3.org/Archives/Public/public-xsl-query/2015Oct/0034.html
https://lists.w3.org/Archives/Public/public-xsl-query/2015Oct/0035.html
https://lists.w3.org/Archives/Public/public-xsl-query/2015Oct/0039.html

Both EnclosedExpr and StringConstructorInterpolation should be modified so that the operand expression is optional.  i.e. 

StringConstructorInterpolation ::= "`{" Expr? "}`"
EnclosedExpr ::= "{" Expr? "}"
Comment 1 Jonathan Robie 2015-10-20 16:26:12 UTC
The Working Group has adopted this change.
Comment 2 Michael Kay 2015-10-21 09:24:46 UTC
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".
Comment 3 Josh Spiegel 2015-10-21 14:49:46 UTC
> 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.
Comment 4 Jonathan Robie 2015-10-27 16:51:26 UTC
Resolved in today's meeting (see minutes).