Skip to content
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

make Operation a Namespace #151

Merged

Conversation

jkhsjdhjs
Copy link
Contributor

@jkhsjdhjs jkhsjdhjs commented Nov 3, 2023

This commit makes Operation inherit from UniqueIdShortNamespace, to implement Constraint AASd-134:

For an Operation, the idShort of all inputVariable/value, outputVariable/value, and inoutputVariable/value shall be unique.

In the DotAAS spec, the attributes inputVariable, outputVariable and inoutputVariable of Operation are defined to be a collection of OperationVariable instances, which themselves just contain a single SubmodelElement. Thus, the OperationVariable isn't really required for Operation, as the Operation can just contain the SubmodelElements directly, without an unnecessary wrapper. This makes Operation less tedious to use and also allows us to use normal NamespaceSets for the 3 attributes, which together with the UniqueIdShortNamespace ensure, that the idShort of all contained SubmodelElements is unique across all 3 attributes.

Aside this, the examples are updated since SubmodelElements as children of an Operation are now linked to the parent. This prevents us from reusing other SubmodelElements as OperationVariables as it was done previously, since each SubmodelElement can only have one parent.

Fix #146 #148

This commit makes `Operation` inherit from
`UniqueIdShortNamespace`, to implement Constraint AASd-134:

For an Operation, the idShort of all inputVariable/value,
outputVariable/value, and inoutputVariable/value shall be unique.

In the DotAAS spec, the attributes `inputVariable`, `outputVariable`
and `inoutputVariable` of `Operation` are defined to be a collection of
`OperationVariable` instances, which themselves just contain a single
`SubmodelElement`. Thus, the `OperationVariable` isn't really required
for `Operation`, as the `Operation` can just contain the
`SubmodelElements` directly, without an unnecessary wrapper. This makes
`Operation` less tedious to use and also allows us to use normal
`NamespaceSets` for the 3 attributes, which together with the
`UniqueIdShortNamespace` ensure, that the `idShort` of all contained
`SubmodelElements` is unique across all 3 attributes.

Aside this, the examples are updated since `SubmodelElements` as
children of an `Operation` are now linked to the parent. This prevents
us from reusing other `SubmodelElements` as `OperationVariables` as it
was done previously, since each `SubmodelElement` can only have one
parent.

Fix eclipse-basyx#146 eclipse-basyx#148
@jkhsjdhjs jkhsjdhjs changed the title make OperationVariable a Namespace make Operation a Namespace Nov 8, 2023
@s-heppner
Copy link
Contributor

Looks good to me

@s-heppner s-heppner merged commit 1d87d2d into eclipse-basyx:improve/V30 Nov 14, 2023
6 checks passed
@s-heppner s-heppner deleted the feature/operation_namespace branch November 14, 2023 12:31
@s-heppner s-heppner added the v3.0 label Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants