-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit recursion depth for SMEs #333
Comments
@arnoweiss even the exact 100 as limit could still cause problems. eclipse-basyx/basyx-java-server-sdk#158 |
Spoke to some colleagues and they used 32 in similar specifications. After all, it's up to the workstream AAS if this should be specified at all (I think it's relevant for interop --> not implementation-specific --> relevant for spec) and then decide on a reasonable number. |
You are probably right. To restrict recursion would not be backward-compatible but we could give a recommendation. I am happy to learn which depth might be appropriate. We should also have a look at existing Submodel Templates and which depth they used so far. |
TF AAS Part 1 2024-06-12 Decision Proposal: For term "Container-Element" see also #420 |
Workstream AAS Specs 2024-06-13 |
* remove zip file, was not added on purpose * fix #333 recursion depth max 32 * fix #333 recursion depth continues fix #388 UML Cardinality * fix #396 continued * matching strategy references * fix figure ContainerElement in SubmodelElement Overview * check to mention all issues closed in v3.1 * minor editorial changes fix chapter structure in mapping * fix #509 Annex Overview Constraints
Is your feature request related to a problem? Please describe.
There should be a decision on a maximal recursion depth of SubmodelElements. Some SubmodelElements may contain arbitrary other SubmodelElements - namely:
This prevents overflow errors and should also serve as a guideline for modeling.
Describe the solution you'd like
Define a maximal recursion depth in the spec. Suggestion: 100.
Describe alternatives you've considered
Leave everything as is. There probably won't be any problems until someone has a really complex scenario where their stack crashes at runtime.
The text was updated successfully, but these errors were encountered: