Repository navigation
Description
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:22eaea09aas-core-meta:560851dc, usingaas_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-\uD7FFstarts 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.
- Go compilation failure — Make read-only sequences of verifications generic #852
- Regex escaping
- XML formatting whitespace
- XML round-trip comparison
- Windows diagnostic paths
Activity
Preserve encoded characters in Go regexes (#855)