You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to have an id field for every repeatable node. This would greatly help the integration between the SDK and our platform for matching data which exists in both places. Some examples:
generating a notice that follows a previous notice (CAN after CN, for example): here we start from the previous notice (as conceptual model), and then want to merge that with data from our platform, for which it is necessary that we can identify which repeatable node instance to merge with corresponding platform data
detecting changes between 2 notices (CN and change, for example): we do this based on comparing conceptual models, based on a kind of "node path". Again the challenge lies in identifying repeatable nodes, since these get some kind "node path index". For nodes with idField, we can use the value of said field, but for the other nodes we fall back to "index among siblings", which relies on the order of the xml elements, which is unreliable.
The problem is that such identifiers would not have meaning for the notice, or for consumers of the notice other than the CA, but then again there are already such fields in some places, so why not have them everywhere? Perhaps everywhere is not even needed, if we can distinguish between entities (which have an identity) and value objects (which are essentially wrappers of values without identity - so implicitly their "id" is the combination of all their values).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
It would be useful to have an id field for every repeatable node. This would greatly help the integration between the SDK and our platform for matching data which exists in both places. Some examples:
The problem is that such identifiers would not have meaning for the notice, or for consumers of the notice other than the CA, but then again there are already such fields in some places, so why not have them everywhere? Perhaps everywhere is not even needed, if we can distinguish between entities (which have an identity) and value objects (which are essentially wrappers of values without identity - so implicitly their "id" is the combination of all their values).
Beta Was this translation helpful? Give feedback.
All reactions