Skip to content

fix: add comment on event propagation#161

Open
nicir wants to merge 3 commits into
factory-x-contributions:mainfrom
nicir:ambiguity
Open

fix: add comment on event propagation#161
nicir wants to merge 3 commits into
factory-x-contributions:mainfrom
nicir:ambiguity

Conversation

@nicir

@nicir nicir commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

WHAT

Minor Wording Changes in the Spec.

WHY

Inaccuracies in the text.

FURTHER NOTES

None.

@nicir

nicir commented Jun 3, 2026

Copy link
Copy Markdown
Contributor Author

Also made major changes to the spec. Ambiguity is now fully removed. PUT requests will only lead to changed events. Also described that there is no parent propagation.

Closing Issue #156 and Ticket TP4A-206

@arnoweiss arnoweiss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the pitch. Some general comments, I think we don't have to change as much as proposed.

Comment thread specs/README.md

Events are emitted on the resource level directly addressed by the operation.
Changes MUST NOT automatically propagate to parent resources.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Events MAY be emitted by the more low-level resources.

Comment thread specs/README.md
| Asset Administration Shell object* | Status code* |
| | Replaced Asset Administration Shell |

<!--

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the rationale behind removal of these Events - there could still be HTTP calls like PUT /shells. Shouldn't those still emit events regardless of changes in the underlying submodels?

Comment thread specs/README.md
| Reference to the Submodel* | Status code* |
| | Created Submodel Reference* |

_Note: Creation or deletion of a Submodel itself does not imply an AAS update event unless the AAS Submodel reference list is modified._

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

Comment thread specs/README.md
_("*" indicates a mandatory parameter)_
_Note: Changes to contained SMEs do not by themselves require a SubmodelUpdated event when the operation addresses a SubmodelElement endpoint._

_When a **PutSubmodel** operation replaces an existing Submodel, a SubmodelUpdated event MUST be emitted.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replacing, I think, would mean "one id stops existing, the other one comes into existence". A PUT operation that has contradicting ids in path and body however will always return HTTP 4xx so I think the scenario doesn't exist.

Comment thread specs/README.md
Additional SubmodelElementCreated, SubmodelElementUpdated, or SubmodelElementDeleted events MUST NOT be emitted._

<!-- If a new SubmodelElement is created (PostSubmodelElement) or deleted (DeleteSubmodelElementByPath), does this update the Submodel itself? -->
_When a **PutSubmodel** operation creates a new SM, a SubmodelUpdated event MUST be emitted, not a SubmodelCreated event.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above

@arnoweiss arnoweiss changed the title Ambiguity fix: add comment on event propagation Jun 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants