STIX 2.0 Proposal15 : Remove abstract base types for "top level" objects (#386)
Consensus has been achieved on this issue. The relevant issues trackers have been marked as such. Any future treatment of this issue will occur within the pre-draft, draft and final specifications.
STIX 1.2.1 contains a set of abstract base types for each "top-level" construct except Observable (which leverages CybOX directly). Each of the "top-level" objects derive from these abstract base types and the abstract base types are leveraged wherever relationships to the "top-level" object concepts are needed.
These abstract base types were included in STIX for 3 reasons:
- to support the potential desire of some user to leverage a completely different implementation for one of the "top-level" concepts rather than the STIX default implementation (e.g. IODEF instead of STIX Incident).
- to support the potential desire of some user to leverage a specialized derivation of one of the default STIX implementations of the "top-level" concepts (e.g. the secret squirrel community wishing to leverage a Threat Actor++ implementation with some domain specific properties unique to them).
- to enable loose coupling of the various "top-level" default implementations in the very explicit domain of XSD Schema serialization
It is proposed that each of the abstract base types for the "top-level" objects be removed from the model and each "top-level" object type stand on its own.
This rationale is supported by the following:
- reason #1 above has never proven out to be likely and would be serious ill-advised anyway
- reason #2 above could still be accomplished without the abstract base types by extending the concrete "top-level" objects themselves
- this sort of serialization-specific limitation could and likely should be conveyed as part of a serialization binding spec rather than an integral part of the implementation independent language model
The orange classes in the below model diagram are the "top level" objects and as you can see they would now extend directly from IDableConstructType or via a contextual intermediary like IdentityType or AssertionType.
This change would make no difference at the serialization level other than it may require some special serialization binding rules for explicit serializations such as XML Schema to enable loose coupling.
N/A
N/A