More restrictive schemas for Reference

[mhrimaz]

Is your feature request related to a problem? Please describe.

Schemas plays an important rule to enforce the constraints and prevent people and tools to create invalid payloads. The current schema does not validate the references in AssetAdministrationShell. The Reference for Submodel should only be ModelReference and refer to Submodel. Similarly, derivedFrom should only be ModelReference and refer to AssetAdministrationShell. This clearly mentioned in the specification, however, not visible in neither JSON schema nor SHACL constraints.

Describe the solution you'd like Schema's should validate as much as possible such constraints.

For example the following payload is valid for an Asset Administration Shell from the perspective of JSON Schema:

{
    "assetInformation":{
        "assetKind":"Instance"
    },
    "id":"Test",
    "modelType":"AssetAdministrationShell",
    "submodels":[
        {
            "keys":[
                {
                    "type":"GlobalReference",
                    "value":"ExampleID"
                }
            ],
            "type":"ExternalReference"
        }
    ]
}

Describe alternatives you've considered Current JSON schema should specialize for such constraints. A pull request (#309 ) provided as a possible solution I can extend it further. However I am not sure how is the impact on other toolings @mristin .

[mristin]

Thanks, @mhrimaz!

This is definitely too difficult to infer automatically at the compiler layer, to the best of my knowledge. However, we could formulate such patches as code and re-apply them on each version.

@sebbader-sap @s-heppner FYI

[mhrimaz]

@mristin Validating all the constraint with actual runtime data is for sure hard. But this issue that I am refering to is more in the direction of current schemas. They are too general at least for this constraint:

In current schema for AssetAdministrationShell.submodels any type of reference is allowed, but it should only be ModelReference<Submodel> . The proposed PR can validate that, but the change in schema might break the code generator, test data generators, ... which I am not sure if it is possible to check that or not.

[mristin]

@mhrimaz sorry, I was not clear. We write these constraints in the formalized meta-model, and these are easy to transpile (and we do that in the SDKs). Hower, transpiling the formalized constraints as class invariants to declarative JSON and RDF schemas is very hard.

Hence, we can not transpile the code you are proposing, but we can keep it as a separate, post-transpilation patch. This provided we have enough woman-hours to maintain these patches.

[arnoweiss]

@mhrimaz - there's a bigger issue here: The constraints the spec makes are largely unenforceable at development-time. Another example for the same phenomenon is AASd-120 which specifies that members of a SubmodelElementList shall have no idShort. I think, you'd require a whole new set of classes like ReferableInSubmodelElementList.

[mhrimaz]

@mhrimaz - there's a bigger issue here: The constraints the spec makes are largely unenforceable at development-time. Another example for the same phenomenon is AASd-120 which specifies that members of a SubmodelElementList shall have no idShort. I think, you'd require a whole new set of classes like ReferableInSubmodelElementList.

@arnoweiss Yeah, I think the whole situation with Reference is pretty messed up.
Metamodel in some places, is too rigid. In some other places, it is very flexible.

But the general issue is that tools don't validate even basic constraints. Take as an example BaSyx/aas4j. You can basically create a Submodel with an id longer than the 2000 (2024) limit.

But at least, it would be better to validate as much as possible to avoid creating invalid examples. Surprisingly, the validator in AAS4j was also removed!

Now, it is my daily job to fix invalid cases for other people. Chances are high that if you take any aasx file from someone, it violates the schema. But the tools that people use to create AAS can easily prevent the creation of these cases, show proper errors, or take other preventative measures. Otherwise, we should just create ad-hoc fixers.

[mristin]

@mhrimazwe wrote:

But the general issue is that tools don't validate even basic constraints.

We are working on aas-core-java and C++ SDK, estimated to arrive in Jan/Feb 2024. Hence, there will be an SDK for every major language that also enforces the constraints in full. Currently, such SDKs exist for C#, Python, Go, TypeScript (see https://github.com/aas-core-works).

The AAS swiss knife already supports constraint validation as a command-line tool (see https://github.com/aas-core-works/aas-core3.0-cli-swiss-knife).