Skip to content

Generated Go SDK for metamodel V3.2 fails compilation and tests #840

Open

Description

@chris-koo

Generating and validating a Go SDK from the V3.2 metamodel exposes
compilation, verification, XML round-trip, and Windows diagnostic
problems.

Originally observed using these local revisions:

  • aas-core-codegen: 22eaea09
  • aas-core-meta: 560851dc, using aas_core_meta/v3_2.py

Problems

Slice arguments prevent compilation

Generated verification calls pass descendant-interface slices to
parameters expecting base-interface slices. Go rejects these calls
because slices are invariant.

For example, passing []ISomeItem to a function expecting
[]IAbstractItem fails even though ISomeItem embeds IAbstractItem.

Valid reference identifiers fail verification

The generated Go SDK rejects these valid reference identifiers,
which are explicitly documented in the V3.2 metamodel:

$sm("https://example.com/sm")#idShort
$sme("https://example.com/sm").someProperty#value

The metamodel's Python verification function accepts both values.
The generated Go regex compiles successfully, but rejects them.

This was reproduced with aas-core-codegen at a27ed72b and
aas-core-meta at 560851dc.

Definition in the metamodel

The examples appear in
matches_reference_identifier.

The identifier-character rule
is:

identifier_character = (
    r"([\x09\x0A\x0D\x20-\x21\x23-\x5B\x5D-\uD7FF\uE000-\uFFFD"
    r'\U00010000-\U0010FFFF]|\\["\\])'
)

The quoted identifier allows XML-serializable characters, with
quotation marks and backslashes requiring escaping.

These ranges exclude an ordinary quotation mark and backslash:

Range Meaning
\x20-\x21 Space through !
\x23-\x5B # through [
\x5D-\uD7FF ] through U+D7FF

The missing character codes are 22, the quotation mark, and 5C,
the backslash. The separate \\["\\] alternative permits their
escaped forms.

Python interprets \x5B and \x5D as literal bracket characters
serving as range endpoints.

Incorrect generated pattern

The Go renderer writes explicitly encoded characters directly into
the regex. Consequently, this fragment:

\x23-\x5B\x5D-\uD7FF

starts becoming:

#-[]-

Go reads #-[ as a range and the following ] as the end of the
character class. That closing bracket should instead be the literal
character starting the next range.

The actual generated Go assignment is:

identifierCharacter := "([\t\n\r -!#-[]-\ud7ff\ue000-\ufffd\U00010000-\U0010ffff]|\\\\[\"\\\\])"

The regex remains syntactically valid, but its meaning changes.
Lowercase letters belong to the intended second range, from ]
through U+D7FF, which is no longer interpreted correctly.

Why V3.2 exposes the problem

V3.1's general XML-serializable string rule uses the larger range
\x20-\uD7FF. This includes brackets without writing them explicitly
as range endpoints.

V3.2's additional reference-identifier rule splits that range to
exclude unescaped quotation marks and backslashes. The brackets
immediately before and after the backslash become explicit endpoints,
exposing this existing weakness in the Go renderer.

Expected behavior

The generated verification should preserve the meaning of the
metamodel's encoded characters and accept its documented examples.

A runtime comparison using the complete patterns confirms:

Documented example Python metamodel Old Go regex Corrected Go regex
$sm("https://example.com/sm")#idShort Accepts Rejects Accepts
$sme("https://example.com/sm").someProperty#value Accepts Rejects Accepts

XML reader rejects formatting whitespace

The XML reader rejects formatting whitespace before closing tags,
reporting errors such as:

Expected an end element value, but got text

XML round-trip tests reject equivalent representations

The generated round-trip tests compare XML text and reject equivalent
lexical representations. For example, these represent the same numeric
value:

<double>42.0</double>
<double>42</double>

Equivalent escaping of quotes and tabs also causes comparisons to fail.

Diagnostic paths differ on Windows

Generation-error messages use platform-dependent path separators.
The golden test expects:

verification/verification.go

Windows produces:

verification\verification.go

This causes the diagnostic comparison to fail.

Expected behavior

The generated SDK should compile, accept valid reference identifiers,
and preserve data through XML round-trips. Equivalent XML
representations should pass round-trip comparisons, and diagnostic
paths should be consistent across platforms.

Progress

Following the review of #841, the fixes are being submitted in separate
PRs. Items will be checked off when their fixes merge.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions