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
The current syntax captures type and id of the parent and represents it as a map entry like syntax where the value of the key entry encodes the type information. This syntax leaves the responsibility of enforcing that a parent is indeed only has a type of trustZone or component to the domain logic after parsing the otm. (First element is deserialized to a one element map, then additional the entry must be validated after creation - I believe a fragile way of checking for consistency. ).
Other elements in the OTM spec however - Representation for example - chose a separate "type" and "id" entry to contain this information. Re-using the same syntax encodes the type information on the syntax level and makes type validation during deserialization possible.
In Java code for example it is quite easy this way to deserialize the element directly to an implementation (either of class TrustZone or that of Component) of the abstract Parent class with a sinlge field ID - what makes perfect sense for an element what is essentially a typed reference to a concrete instance of an other element.
In case this PR is accepted, I would recommend changing the possible types of Parent to trustZoneRef and componentRef (or similar) emphasizing the distinction between the actual parent element and the element referencing it.
Kr. Daniel
The text was updated successfully, but these errors were encountered:
Please refer to #6
for a concrete realization suggestion.
fixbits
changed the title
Parent object is not consistent with the rest of the objects
[Suggestion] Parent object is not consistent with the rest of the objects
Sep 12, 2022
Dear Team,
The current syntax captures type and id of the parent and represents it as a map entry like syntax where the value of the key entry encodes the type information. This syntax leaves the responsibility of enforcing that a parent is indeed only has a type of trustZone or component to the domain logic after parsing the otm. (First element is deserialized to a one element map, then additional the entry must be validated after creation - I believe a fragile way of checking for consistency. ).
Other elements in the OTM spec however - Representation for example - chose a separate "type" and "id" entry to contain this information. Re-using the same syntax encodes the type information on the syntax level and makes type validation during deserialization possible.
In Java code for example it is quite easy this way to deserialize the element directly to an implementation (either of class TrustZone or that of Component) of the abstract Parent class with a sinlge field ID - what makes perfect sense for an element what is essentially a typed reference to a concrete instance of an other element.
In case this PR is accepted, I would recommend changing the possible types of Parent to trustZoneRef and componentRef (or similar) emphasizing the distinction between the actual parent element and the element referencing it.
Kr. Daniel
The text was updated successfully, but these errors were encountered: