Previously the requirement that properties ending in `_ref(s)` were
instances of an appropriate type capable of containing a STIX
`identifier` (the current interpretation of section 3.1 of the STIX 2.1
spec) was only enforced for custom observables. This change refactors
the property checks for custom objects to enforce this and the STIX 2.1
property name requirement (also from section 3.1) in a common helper,
therefore extending the enforcement of both requirements to all custom
object types created by downstream projects.
There is a special case carved out for STIX 2.0 observables which are
required to contain "object references" rather than identifiers. This
special logic is encoded in the reference property validation helper and
enabled by a kwarg which is passed exclusively by the custom observable
registration helper.
class map structure is keyed by normal "X.Y" style versions,
the convenience that function provided is no longer necessary.
So it no longer makes sense to have the function (at least,
not for that reason). Change users of that function to use
the STIX2_OBJ_MAPS structure directly.
level with STIX versions in the same format as is used everywhere
else in the API: "X.Y", as opposed to the "vXY" format used by
the version-specific python packages. This eliminates all of
the awkward conversion from public API format to "vXX" format.
Also a little bit of code rearranging in the registration module
to ensure that some STIX 2.1-specific checks are done whether
version 2.1 is given explicitly or is defaulted to.
In the same module I also added a missing import of
stix2.properties, since my IDE was claiming it could not find a
function from that module.
- stix2.registry, which contains the class mapping structure
and code for scanning stix2 modules for its initial population
- stix2.registration, which contains code used to register custom
STIX types with the registry
- stix2.parsing, which contains code for creating instances of
registered stix2 classes from raw dicts.
This is intended to reduce circular import problems, by giving
dependent code the ability to import a module which has exactly
the functionality it needs, without pulling a lot of other stuff
it doesn't need. Fewer imports means less chance of an import
cycle.
maybe-sybr