If you want to show a relationship between two objects within STIX at present, you can either create a top-level object and reference that object from another object (Reference), or you can embed the object directly within the other object (Embed).
This embed vs reference decision complicates matters for implementers. Rather than just supporting one way of doing things, implementers need to support both ways of tracking the objects, complicating things at the deserialization step.
POTENTIAL ANSWER
We can rectify this issue by mandating that all relationships between objects that will likely be related to multiple other objects must be made using the relationship object (discussed elsewhere in this document) – never embedded. Any Object that is likely to be reused again must be created independently, and have its own referenceable Object ID. The object will then be referenced from the other Object.
If Objects will only ever have a 1:1 relationship with one other Object, then they should actually be flattened into the containing Object to become part of the containing Object itself.
We envisage all relationships between objects being described using a separate independent Relationship object (see section 8 - Cannot generate a relationship between two third-party objects), all except for the Indicator to Pattern (Observable Pattern) Relationship, where the Boolean Condition described within the Indicator would describe the pattern that ‘triggers’ the Indicator.
PROBLEM
If you want to show a relationship between two objects within STIX at present, you can either create a top-level object and reference that object from another object (Reference), or you can embed the object directly within the other object (Embed).
This embed vs reference decision complicates matters for implementers. Rather than just supporting one way of doing things, implementers need to support both ways of tracking the objects, complicating things at the deserialization step.
POTENTIAL ANSWER
We can rectify this issue by mandating that all relationships between objects that will likely be related to multiple other objects must be made using the relationship object (discussed elsewhere in this document) – never embedded. Any Object that is likely to be reused again must be created independently, and have its own referenceable Object ID. The object will then be referenced from the other Object.
If Objects will only ever have a 1:1 relationship with one other Object, then they should actually be flattened into the containing Object to become part of the containing Object itself. We envisage all relationships between objects being described using a separate independent Relationship object (see section 8 - Cannot generate a relationship between two third-party objects), all except for the Indicator to Pattern (Observable Pattern) Relationship, where the Boolean Condition described within the Indicator would describe the pattern that ‘triggers’ the Indicator.