i see, thanks for clarification. In this case, container is just sort of sugar coat.
You can implement this as either action statement, or config false data.
If you use
action statement, you can define all the data as
output leaves, none of which will be mandatory. User then invokes action and gets none/some/all output leaves from your implementation as a result.
Other way is to implement it as config false data -> and them implement either data provider for on-request responses, or just send it to CDB oper datastore / delete it from CDB as necessary by the managing app that has internal data…
Whichever path you take, you can then use container as @waitai proposed above, or even presence container. For action, you even don’t have to use container at all, as all the optional leaves are wrapped by the managing action statement automatically.
config false vs action depends on specific data… whether you can imagine it belonging together with other operational state, or rather isolated event driven info (action).