The WG considered this issue in the face to face meeting today.  There was some sentiment on each side of the question, but in the end the prevailing view was that the change proposed here should not be made.  In general, an XML serialization of a context-free grammar can be designed to be as light-weight as is consistent with clarity, or to match the grammar as closely as possible, with each non-terminal turning into an element type.  While XQueryX is not absolutely consistent in this regard, the general design approach is toward close alignment with the grammar.  

Accordingly, I have been asked to close the issue as WORKSFORME.

(In reply to C. M. Sperberg-McQueen from comment #1)
> The WG considered this issue in the face to face meeting today.  There was
> some sentiment on each side of the question,

That surprises me. In my original post, I gave supporting examples of how the XQueryX schema has handled analogous situations in the past. Did the sentiment on the other side of the question provide any reasoning for treating these new cases differently?

> In general, an
> XML serialization of a context-free grammar can be designed to be as
> light-weight as is consistent with clarity, or to match the grammar as
> closely as possible, with each non-terminal turning into an element type.

Agreed.

> While XQueryX is not absolutely consistent in this regard, the general
> design approach is toward close alignment with the grammar.

If "close alignment with the grammar" is meant to refer to the second approach described in the previous sentence, then I disagree that that's the general approach used by XQueryX. I think it's actually closer to the first approach. Can anyone give examples (aside from the constructs in question) of how it's *not* "as light-weight as is consistent with clarity"? Because I can certainly give lots of examples where it *doesn't* turn each non-terminal into an element type.

This was discussed again in the teleconference on 2014-11-18 to consider MDyck's comment #2.

It was decided by the WG to leave the decision to the editors (Jim & Michael) to agree the resolution...


Q2.4.1 Bug 27119 - [XQX31] unnecessary nesting in array constructors
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27119

Status: Reconsider decision made as F2F based on MDyck's comment #2

DECISION: The XQueryX 3.1 editors are empowered to resolve the XQueryX 
grammar issue in bug 27119 using their best judgement.

I don't wish to re-open this issue, but in comment 2 Michael Dyck asks

    Can anyone give examples (aside from the constructs in question) 
    of how it's *not* "as light-weight as is consistent with clarity"? 

In connection with other work, I had occasion just now to ask the grammar applet at [1] to generate an XQueryX translation of the expression "1 + 2".  

[1] http://www.w3.org/2013/01/qt-applets/xquery30/

The result is:

<xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.w3.org/2005/XQueryX
                                http://www.w3.org/2005/XQueryX/xqueryx.xsd">
  <xqx:mainModule>
    <xqx:queryBody>
      <xqx:addOp>
        <xqx:firstOperand>
          <xqx:integerConstantExpr>
            <xqx:value>1</xqx:value>
          </xqx:integerConstantExpr>
        </xqx:firstOperand>
        <xqx:secondOperand>
          <xqx:integerConstantExpr>
            <xqx:value>2</xqx:value>
          </xqx:integerConstantExpr>
        </xqx:secondOperand>
      </xqx:addOp>
    </xqx:queryBody>
  </xqx:mainModule>
</xqx:module>

The presence of so many single-child elements and the close alignment of element names with non-terminals both seem to this observer to place the XQueryX design much closer to the XML modeling of a concrete parse tree than to the modeling of an abstract syntax tree "as light-weight as is consistent with clarity".  Michael Dyck points out that there exceptions to the general rule of turning each non-terminal in the concrete parse tree into an element; that does seem to show that XQueryX is not quite as far towards the end of the spectrum as I had thought.

But I believe MD exaggerates when he puts it closer to the other end of the spectrum. 

One lighter-weight translation that seems to me consistent with clarity would be:

<xqx:mainModule xmlns:xqx="http://www.w3.org/2005/XQueryX"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="http://www.w3.org/2005/XQueryX
                                    http://www.w3.org/2005/XQueryX/xqueryx.xsd">
  <xqx:queryBody>
    <xqx:addOp>
      <xqx:integerConstantExpr>1</xqx:integerConstantExpr>
      <xqx:integerConstantExpr>2</xqx:integerConstantExpr>
    </xqx:addOp>
  </xqx:queryBody>
</xqx:mainModule>

This translation omits the elements module, firstOperand, secondOperand, and value.  In general, a lighter-weight translation would result from systematically deleting all nodes in the concrete parse tree which have only single children, and the promotion of their children in their place.  A more thoroughly ruthless application of this principle here would result in omitting  queryBody and mainModule as well, so that the XML representation would be:

<xqx:addOp xmlns:xqx="http://www.w3.org/2005/XQueryX"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.w3.org/2005/XQueryX
                                http://www.w3.org/2005/XQueryX/xqueryx.xsd">
  <xqx:integerConstantExpr>1</xqx:integerConstantExpr>
  <xqx:integerConstantExpr>2</xqx:integerConstantExpr>
</xqx:addOp>

A designer seeking a lightweight XML representation in preference to close modeling of the grammar might also prefer different element names:

<xqx:sum xmlns:xqx="http://www.w3.org/2005/XQueryX"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.w3.org/2005/XQueryX
                              http://www.w3.org/2005/XQueryX/xqueryx.xsd">
  <xqx:integer>1</xqx:integer>
  <xqx:integer>2</xqx:integer>
</xqx:sum>

I am not adamant by any means that no changes along the line of Michael Dyck's suggestion should be made -- for this specific case.  I think that it would be somewhere between very unwise and meaningless to propose that the entire philosophy of the XQueryX schema architecture be revised to a wholly minimalist approach, as that would instantly make XQueryX 3.1 completely incompatible with XQueryX 3.0.  But I don't think that jmdyck is proposing that we go that far. 

I am inclined to NOT make jmdyck's proposed changes for one reason only: It requires additional work on my part for no gain at all.  I admit that the necessary changes would not be large, but would also assert that the schema is not "broken" as it is and that there would be no benefits to any expected user of XQueryX to make such a change. 

Please note that I have NOT yet discussed this directly with Michael, because he's still in the process of finalizing his move from Toronto to Ottawa.  I would like to have his agreement (or at least his resigned acceptance :P ) to my inclination before considering this issue fully resolved. 

I thank MSM for his reducto ad absurdum argument, which may or may not help jmdyck to acquiesce.