class in the registry when you have an instance of one of those
classes. Because in that case, you can just get the class of the
instance and not deal with the registry at all.
functions. Changed some ">= 2.1" stix version semantics to be
"== 2.1", because we don't have any version >= 2.1, so they are
currently equivalent, and the is_*() functions don't support
STIX version ranges. They only support exact versions. We can
look at this again if a newer STIX version ever emerges.
Also added a class_for_type() function to the registry module,
which was useful for the versioning module changes described
above. I thought that function would be helpful in the parsing
module, to simplify code there, so I changed that module a bit
to use it.
dict/mapping values: do a simple verification of the value's
STIX version, not just its type. Added a lot more unit tests to
test behavior on dicts. To make the implementation work, I had
to move the detect_spec_version() function out of the parsing
module and into utils. So that required small changes at all
its previous call sites.
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.
properties from being changed, if a UUIDv5 is in use. Changing
one of those properties would imply an ID change, which is not
allowed across versions. Also:
- add a trailing comma
- change unchangable_properties to a set instead of a list,
in case there are dupe props between STIX_UNMOD_PROPERTIES and
sco_locked_props
Michael Chisholm