Where this stands
Three layers of checking exist today, and they establish less than the words suggest:
| Layer |
Establishes |
| JSON Schema, metamodel 3.0 + 3.1 + 3.2 |
the document is shaped the way the metamodel says |
Member gate over every modelType |
no member outside its class, derived from the schemas' inheritance chain |
External loader (aas-core3.0, metamodel 3.0) |
a strict implementation can actually ingest it |
Together those mean the output is a valid AAS document. They do not mean it is conformant, and they say nothing at all about whether it is understandable.
The gap worth being precise about: every semanticId this crate emits is in the urn:odal-node: namespace. That is deliberate — the provenance rule refuses to coin an identifier in another organisation's namespace, and every submodel template binding is flagged a placeholder. The consequence is that the documents are semantically opaque: a consumer's tooling has no dictionary in which urn:odal-node:aas:property:co2e-per-unit:1.0 resolves to anything. Well-formed, and private.
Nothing below is scheduled. This exists so the answers are found once rather than re-derived, and so nobody mistakes "valid" for "conformant" in public wording.
1. Submodel-template conformance
BatteryTechnicalData, TextileMaterialDeclaration and the rest are this project's own inventions. No published IDTA submodel template stands behind any of them, and no check compares them to one.
This is the difference between a document a partner's toolchain can open and one it can use. Opening is solved; using is not.
Concretely:
- Identify which published templates overlap what is already emitted. The Carbon Footprint template is the strongest candidate — it is published, narrow, and covers a field every product group already carries.
- Map onto one template end to end rather than several partially. A partial mapping across five templates is worth less than a complete one across a single template.
- Add a check that the mapping holds, so it cannot silently drift the way hand-maintained bindings do.
2. Concept identifiers with real provenance
Adopting a third-party vocabulary — ECLASS IRDIs, IEC CDD entries — is what makes properties machine-comparable outside this system.
Two costs, and neither is engineering:
- Licensing. Some dictionaries are not freely redistributable. Determine what may be embedded in an Apache-2.0 crate before any identifier is written down.
- Verification. The rule in
semantic_ids/ requires a named person who checked each identifier against the issuing authority's own source, recorded with a date. The allowlist is deliberately empty. This cannot be automated — automating it is exactly the failure it exists to prevent.
A plausible-looking identifier is the specific hazard here. There is already a regression test asserting that fabricated identifiers in standards-body namespaces are refused.
3. Conformance certification
Two distinct things get called this:
Passing IDTA's published test tooling — achievable, and the strongest claim available without a formal process. Requires pinning the tooling version and reporting exactly what was in scope.
Certification through IDTA's own process — organisational: membership, submission, a defined scope, and a certificate that names a version. Every subsequent release re-raises the question.
Either way, the claim is narrower than it sounds. It attests that an AAS document is valid AAS. It does not attest that a Digital Product Passport is correct, and no such certification currently exists to obtain.
4. Loader coverage is 3.0-only
Documents are schema-validated against 3.0, 3.1 and 3.2, but loaded through a 3.0 implementation. So the loader-level check — the only one that catches members no schema sees, because no revision sets additionalProperties — is 3.0-scoped.
The revisions genuinely disagree in ways that reach this output. The idShort rule moved in both directions between 3.0 and 3.1: 3.1 permits interior hyphens 3.0 forbids, and requires two or more characters where 3.0 accepts one. A 3.1/3.2 loader would close that.
Acceptance
Deliberately none. Splitting a scoped, actionable issue out of this is the point; closing this one wholesale is not.
Wording constraint, until the above is done
- ✅ "passes
aas-core3.0 1.1.4 for metamodel 3.0"
- ✅ "schema-valid against IDTA-01001 metamodel 3.0, 3.1 and 3.2"
- ❌ "IDTA-conformant"
- ❌ "interoperable" / "semantically interoperable" — not until §1 or §2 lands
Related
Depends on the external-oracle work; the loader named above is the first half of it.
Where this stands
Three layers of checking exist today, and they establish less than the words suggest:
modelTypeaas-core3.0, metamodel 3.0)Together those mean the output is a valid AAS document. They do not mean it is conformant, and they say nothing at all about whether it is understandable.
The gap worth being precise about: every
semanticIdthis crate emits is in theurn:odal-node:namespace. That is deliberate — the provenance rule refuses to coin an identifier in another organisation's namespace, and every submodel template binding is flagged a placeholder. The consequence is that the documents are semantically opaque: a consumer's tooling has no dictionary in whichurn:odal-node:aas:property:co2e-per-unit:1.0resolves to anything. Well-formed, and private.Nothing below is scheduled. This exists so the answers are found once rather than re-derived, and so nobody mistakes "valid" for "conformant" in public wording.
1. Submodel-template conformance
BatteryTechnicalData,TextileMaterialDeclarationand the rest are this project's own inventions. No published IDTA submodel template stands behind any of them, and no check compares them to one.This is the difference between a document a partner's toolchain can open and one it can use. Opening is solved; using is not.
Concretely:
2. Concept identifiers with real provenance
Adopting a third-party vocabulary — ECLASS IRDIs, IEC CDD entries — is what makes properties machine-comparable outside this system.
Two costs, and neither is engineering:
semantic_ids/requires a named person who checked each identifier against the issuing authority's own source, recorded with a date. The allowlist is deliberately empty. This cannot be automated — automating it is exactly the failure it exists to prevent.A plausible-looking identifier is the specific hazard here. There is already a regression test asserting that fabricated identifiers in standards-body namespaces are refused.
3. Conformance certification
Two distinct things get called this:
Passing IDTA's published test tooling — achievable, and the strongest claim available without a formal process. Requires pinning the tooling version and reporting exactly what was in scope.
Certification through IDTA's own process — organisational: membership, submission, a defined scope, and a certificate that names a version. Every subsequent release re-raises the question.
Either way, the claim is narrower than it sounds. It attests that an AAS document is valid AAS. It does not attest that a Digital Product Passport is correct, and no such certification currently exists to obtain.
4. Loader coverage is 3.0-only
Documents are schema-validated against 3.0, 3.1 and 3.2, but loaded through a 3.0 implementation. So the loader-level check — the only one that catches members no schema sees, because no revision sets
additionalProperties— is 3.0-scoped.The revisions genuinely disagree in ways that reach this output. The
idShortrule moved in both directions between 3.0 and 3.1: 3.1 permits interior hyphens 3.0 forbids, and requires two or more characters where 3.0 accepts one. A 3.1/3.2 loader would close that.Acceptance
Deliberately none. Splitting a scoped, actionable issue out of this is the point; closing this one wholesale is not.
Wording constraint, until the above is done
aas-core3.01.1.4 for metamodel 3.0"Related
Depends on the external-oracle work; the loader named above is the first half of it.