fixes.
- Fixed bugged logic in _STIXBase._check_at_least_one_property(),
and revamped the code to be simpler and clearer.
- Changed custom extension registration to auto-create an
"extension_type" property based on the attribute of that
name on the custom class, if present.
- The custom extension registration change above uncovered
what seemed like a bug in a unit test: a custom extension
was registered, but it was not given an extension type. The
test used the extension as extension_type="property-extension";
this now causes a standard error about an extra property. I
fixed the test to assign the custom extension the proper type.
- Changed an error message "Cannot determine extension type."
At that point in the code, we in fact have a registered
extension type and the class for it, so it didn't seem to make
any sense. I changed it to say that an extension of that type
couldn't be created from type of value given. Because this is
really about typing (in both the old and new code), I also
changed the exception class to TypeError.
- Changed customization behavior: unregistered
"extension-definition--" style extensions are no longer
considered custom. Their mere presence can no longer be
considered a customization, since it doesn't fit the
criteria, and in fact the extension mechanism is supposed to
supplant the old customization system anyway. Unregistered
extensions of other types are still considered custom.
- Fixed up unit tests according to the exception message
change.
- Added a unit test for unregistered "extension-definition--"
style extensions.
properties are now always accepted and not considered
customizations (has_custom will be False). Just commented out
the enforcement code and xfail'd the unit tests, which makes it
easy to reinstate these behaviors later. It was decided this
is too likely to break user code, and we don't currently have
a way to disallow customizations in other places while still
allowing custom open vocab values. Safest to always allow
custom open vocab values, for now.
available after the rebase. This simplifies the implementation.
Also made utils.to_enum() a module public function, since I
needed to use it outside that module. Misc pre-commit stylistic
fixes.
constraints (i.e. both generic type categories and specific
types). Also:
- more expansion/refinement of reference property unit tests
- bugfix: SROs are in OBJ_MAP too, it's not just SDOs! Oops...
- pre-commit stylistic fixes
work when a whitelist of generic category types is used.
Disallow hybrid constraints (both generic and specific at the
same time). Add more unit tests.
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.
TypeProperty uses a fixed value, so check() was never called. This way
also runs the check at object registration time because the wrapper
creates an instance of TypeProperty and doesn't have to wait for the
object to be instantiated so clean() can be called.
Also fix some tests.
and sometimes a STIX property name. It didn't work (caused
crashes under some circumstances). Now, attributes whose names
conflict with Mapping methods will have the Mapping
interpretation. Same-named STIX object properties will not be
accessible as attributes.
Michael Chisholm