Default Values in Schemas

[sebbader-sap]

The metamodel knows several default values for attributes, e.g., HasKind/kind = ModelingKind.Instance. RDF/SHACL provides an option to encode such information explicitly in the schema:

aas:HasKindShape a sh:NodeShape ;
    sh:targetClass aas:HasKind ;
    ...
    sh:property [
        sh:path <https://admin-shell.io/aas/3/0/RC02/HasKind/kind> ;
        ...
        **sh:defaultValue <https://admin-shell.io/aas/3/0/RC02/ModelingKind/Instance> ;**
        ...
    ] ;
.

XML and JSON seem to have similar features. As a significant amount of developers will only use the standards, providing information about the defaults certainly adds value.

[mristin]

@sebbader-sap thanks for the suggestion!

Status

We discussed this feature initially, and planned to implement it. The original idea was to model the default values as default values of the constructor arguments.

It turned out that default values involve invariants of their own and also need to be called through getters in the class invariants. Therefore, we finally settled on the approach to model them as getter functions:

https://github.com/aas-core-works/aas-core-meta/blob/931b355682c4a7b84a2fb94932cf09bcf7ce9a1f/aas_core_meta/v3rc2.py#L2824

While most of them do represent primitive values and involve simple null coalescing, I anticipate in the future that more complex logic will be needed.

The current C# SDK includes the getters with a default value already:

https://aas-core-works.github.io/aas-core3.0rc02-csharp/getting_started/create_get_set.html#getters-with-a-default-value

Thoughts

Here is one possible solution to provide default values in the schemas. I'm listing the tasks both for discussion and for future reference:

1) Make simple X_or_default functions transpilable instead of implementation-specific.

We would have to introduce null coalescing in the parsing and intermediate representation stage, but this is not too difficult.

The only reason we haven't done this already is the lack of time. We had a short try at it (less than 2 hours), but had to abort the action as we realized that transpiling pre-conditions and post-conditions involves more thinking and work (especially when it comes to inheritance with pre-conditions due to "require else" logic!).

2) Infer the default values from the X_or_default functions, where possible.

This is similar to what we did with the length and pattern constraints.

We would have to refactor the inference structure into a class instead of passing the inference results as separate arguments, as now there would be too many unbundled data to be passed around. This refactoring involves labor, but no particular mental load.

3) Check if default values in XML and JSON really make sense.

I could imagine that the default values could also confuse the user as she might think that the values would be somehow magically set if not provided. Honestly, I have no idea as I have never encountered default values in the wild myself, so we would need to interview advanced users of the two schemas.

Timeline

I am personally tied to the generation of SDKs Python and TypeScripts, and also have to work on two other projects. It is hard for me to promise when I'd be able to work on this feature in the next 4-6 months.

However, this would be a great first feature if anybody would like to have a deep dive into aas-code-codegen! We might initially limit the scope to include only functions without preconditions to make the transpilation part of the task a bit easier.

While I wouldn't have time for the hands-on development in the near future, I would be available for pair-programming sessions, coaching & reviewing and general discussions.

[sebbader]

Thanks for the comprehensive response. While it seems like a feasible entry step into the project, as you wrote, this sentence also holds true for me:

It is hard for me to promise when I'd be able to work on this feature in the next 4-6 months.

Let me think about it a bit. I did not intend this issue as an urgent feature request, rather a place to not forget about it. It's therefore not time-critical for me anyway.

[mristin]

@sebbader-sap let's simply leave it open for now. Maybe ping me in 6 months if you still need it then, and then we see what to do about it?

A deep dive into the code requires at least 2-3 weeks.

[mristin]

I'm closing this issue due to inactivity. The default values seem not to be relevant in the short or mid-term. We can re-open this issue if the discussion restarts at some point.