Re: QT4CG meeting 093 draft minutes, 8 October 2024

On 08/10/2024 17:36, Norm Tovey-Walsh wrote:
>   * MK reviews the proposal in 4.12.3.1 Computed Element Constructors.
>            + ... If you want to use reserved names like div and value, you
>              have to quote them.
>            + ... That's pretty much it, but the text is restructured a bit.
>       * CG: Does that mean we can get rid of the rule for standalone
>         expression again?
>       * MK: I hope so, perhaps JWL can help review the ambigutities again.
>       * JWL: I'll do that once this is merged.

I've generated the XPath and XQuery iXML grammars from the definitions 
as of 11th October, including removal of StandaloneExpr, and the 
addition ofBareMapConstructor to PrimaryExpr. (I'll publish the new 
grammars early next week)

As far as I can tell, running the test-suites, there are no new 
ambiguities introduced, and the use of UnreservedName resolves the 
CompElemConstructor ambiguities. That is:

    element mod {}

parses unambiguously as:

    <MultiplicativeExpr MultiplicativeOps="mod">
        <AxisStep>
         <QName local="element"/>
        </AxisStep>
        <BareMapConstructor/>
       </MultiplicativeExpr>

whereas:

    element "mod" {}

parses as:

    <NodeConstructor>
        <CompElemConstructor>
         <QuotStringLiteral>mod</QuotStringLiteral>
         <EnclosedExpr/>
        </CompElemConstructor>
       </NodeConstructor>

and

    element somethingElse {}

parses as:

    <NodeConstructor>
        <CompElemConstructor>
         <QName local="somethingElse"/>
         <EnclosedExpr/>
        </CompElemConstructor>
       </NodeConstructor>

I think that UnreservedName might actually only need to exclude /binary 
operators/ that are NCNames,(eg: and, or, ne, eq, is etc.) plus a couple 
of other specials which can be followed by an open brace (e.g. return) 
rather than the entirety of the literal terminal set 
<https://qt4cg.org/specifications/xquery-40/xquery-40.html#lexical-structure> 
which are NCNames. But it's probably not worth making the situation more 
complex. After all by using a literal string on and expression you can 
form up the node name from any valid NCName.


*John Lumley* MA PhD CEng FIEE
john@saxonica.com