@qt4cg statuses

The specification of err:XPST0003 says:

err:XPST0003

It is a static error if an expression is not a valid instance of the grammar defined in A.1 EBNF.

But recent changes to record declarations call for issuing err:XPST0003 in cases conforming to the grammar:

• for labeled records with constructor functions (§5.20.2):

  The names of the fields must be simple NCNames in no namespace; the names must not be written as string literals [err:XPST0003]. Note: This is described here as a semantic constraint, but an implementation might choose to impose it at the level of the grammar.

• for fields declared as %static (recordTypeDecl-137):

  <test-case name="recordTypeDecl-137" covers-40="PR2979">
     <description>Static field must have an initial value</description>
     <created by="Michael Kay" on="2026-10-29"/>
     <test><![CDATA[
        declare record local:rectangle(x, y, %static area);
        local:rectangle(4, 5) =?> area()
     ]]></test>
     <result>
        <error code="XPST0003"/>
     </result>
  </test-case>
  

The grammar fragment that covers both cases is this:

ExtendedFieldDeclaration ::= "%static"? FieldDeclaration (":=" ExprSingle)?
FieldDeclaration         ::= FieldName ("as" SequenceType)?
FieldName                ::= NCName | StringLiteral 

It currently unconditionally allows both StringLiteral as FieldName, and uninitialized static fields.

To keep the record declaration rules aligned with the definition of err:XPST0003, my proposal is:

• to define a dedicated static error code for the case where a record declaration that generates a constructor function contains a field name written as a string literal. The accompanying note should be removed or revised accordingly.
• to make the initializing expression mandatory for %static fields in the grammar:

  ExtendedFieldDeclaration ::= FieldDeclaration (":=" ExprSingle)?
                             | "%static" FieldDeclaration ":=" ExprSingle
  

  This preserves optional initialization for non-static fields and makes a missing initializer on a static field a grammar violation.

Another attempt to get (labeled) records extensible:

• It is close to what has originally been proposed in #2567.
• I am optimistic that a processor can often find out whether a record shall be internally treated as extensible, which is why I haven’t added any %extensible or %final annotations.
• However, I believe we will make our life much easier by going without restricts.

Closes #2567

Fix #3035

The formalism for evaluating regular expressions gives the impression (and has the intent) that the results of all regex functions can be obtained from knowledge of matching segments: in effect, that the output of matches(), tokenize(), replace() etc can all be derived from the result of fn:matching-segments. However, this is not the case. Consider the two expressions

matching-segments("a", "(a(b?))")
matching-segments("a", "(a)(b?)")

These produce the same result, namely

{"substring":"a", "position":1, "groups":
             {1:{"value":"a","position":1,"nr":1,"name":()},
              2:{"value":"","position":2,"nr":2,"name":()}
             }
}

However the expected result of fn:analyze-string in the two cases is different: in the first case, group 2 is a child of group 1, in the second case, it is a sibling,

I believe that there are many cases where a labeled record type is useful, but it is inappropriate to provide the default constructor function for the record type.

This is exemplified by the built-in labeled record types. Most of these are defined as the return type of a function, and the appropriate way to create an instance of the record type is by calling that function.

Consider also the worked example set:atomic-set. The library module defining this type defines a custom constructor function, called for example as set:of(("a", "b", "c")). The default constructor function, by contrast, takes as its input a map; this exposes internal implementation details, and although we can't prevent direct access to the internal structure, we really don't want to encourage people to use it. We could use the proposed integrity constraint mechanism to ensure that the supplied map has the correct form, but this might impose significant performance overheads.

Because an implicit constructor function is created with the name of the record type, it's impossible to create a user-defined function with that name that performs a more nuanced construction, for example with extra validation and creation of internal data fields.

So I think we should certainly provide the opportunity to disable implicit creation of a constructor function, and I would go further and say, from my experience, that this should be the default.

We also create constructor functions for a simple record type declared in a "declare type" declaration. In this case the constructor function offers very little convenience over direct use of the map constructor, and in my view it is likely to be confused with the different semantics of a constructor function for labeled record types. I therefore propose that constructor functions should not be available for simple record types.