substitutionGroup for Data Specifications

[sebastiankb]

What? Currently, the XSD definitions of the AAS are designed in that way that it only include data specifications that are known during the specification phase. Newly developed data specifications must wait until a new AAS version is released, which can take a while.

Idea Define data specification more flexible in the AAS XSD that also allows new or not known external XSD-based data specification during runtime. Thus, the Data Specifications can be maintained by the data specification owner rather than maintained by IDTA.

Technical Solution AAS XSD introduces the usage of XSD substitutionGroup for data specifications. Please find here the slides that explain how the XSD should be defined.

[mristin]

@sebastiankb thanks for writing this up!

Just a note related to generated SDKs and the generated schemas as of 2022-12-19:

After a discussion with @BirgitBoss in June 2022, we concluded that the schemas should be unified in a single file. We could not resolve cyclical dependencies (embedded specification is in the "core" part pointing to the "data spec" part, while there are also types of "core" part used in "data spec" part).

Another major problem is that we designed aas-core-codegen to generate schemas and SDKs in a non-modular way. Changing that would require a substantial effort (vague estimate: 6 months).

Additionally, we'd have to come up with an approach how to achieve the same in JSON. Since JSON usually comes without namespaces, this can be difficult (but not impossible).

My 2 rappen regarding modular schemas: Given how much dynamic schemas usually hurt the interoperability, or come with an enourmous complexity (dependency hell), I would personally recommend an alternative approach for bleeding-edge features. Namely, instead of modularizing the schema and allowing different module versions, to simply extend their schemas either:

1) manually, by extending the XSD and their code, or 2) to write aas-core-meta meta-model and generate bleeding-edge schemas, SDKs etc. with aas-core-codegen.

[BirgitBoss]

Data specifications are designed to allow also bilateral interoperability and to have separate life cycles. They will be maintained in separate documents in the future (with V3.0 already). So far we did not allow data specifications not standardized by IDTA but the concept itself does support exactly this. And industry is requiring it.

In the current specification there is exactly one common data type left: Reference It can just be copied to two name spaces so that there no cycles?

The conclusion to have everything in a single file in V3.0RC02 was because of the time frame; in the long run we will need a modular approach (security - for example - also had a separate namespace from the very beginning.)

So far we do not have a good solution for JSON. But for xml I like the solution and it was also approved by the working group AAS.

We need to analyze what we can do with acceptable effort in V3.0.

[mristin]

I'll just toss an idea here (as well as in email correspondence with some other people): use submodels to model both the security and data specifications.

If I understand correctly, this is how security is implemented in aasx-server right now, and seems to work very well.

This allows to leverage all the instruments already developed or to be developed for submodels (template validation, access, registries, de/referencing, operations etc.). The notion of submodel needs to be extended a bit, but that is not a big deal in my book.

[mristin]

@sebastiankb should we rename the title to "Modularization of schemas" or something similar?

[sebbader-sap]

use submodels to model both the security and data specifications.

Using the submodel concept for managing AAS-content ('regulating' as in IT security & 'explaining' as in semantic meaning & other tasks we are not even aware of) has one advantage: the number of structural elements is a bit lower.

But it introduces major issues:

1. I don't want to be forced to look into a data asset (here: submodel) to understand if I was allowed - or not - to look into it.
2. I don't want to store my permissions inside my productive data as I need to manage it separately. And different personas/roles/applications will do this anyway.
3. The value proposition of the AAS is the I4.0 Digital Twin, not a new access or usage control language. XACML, ODRL, Rego etc. are out there, with good communities and tool support.
4. The value proposition of the AAS is the I4.0 Digital Twin, not a new ontology or semantic explanation language.

I could extend this list but it more or less comes down to one statement: Let's treat different things differently. Let's not add the complexity/expressiveness of security models to (use case-focused) submodels and let's not make a security object bother about submodel structures. Same for data specifications vs. submodels.

[sebbader-sap]

Regarding the original topic: As long as we do not have a convincing pattern for JSON, I see this approach as blocked. Even though I agree that a more flexible pattern adds (a lot of) value, introducing such structural differences between the schemas is a no-go. Therefore, I'd say it should be our first priority to come up with a JSON pattern before we continue the discussion for XML.

[BirgitBoss]

@sebastiankb should we rename the title to "Modularization of schemas" or something similar?

Modularization of schemas makes sense independently from this new approach for data spec handling, so I would not rename it