respect to properties. Before, properties were declared on
toplevel-property-extension extensions as if they were going
to be used in the normal way (as actual properties on instances
of the extension), but they were not used that way, and there
was some ugly hackage to make it work. Despite the fact that
property instances were given during extension registration,
they were not used to typecheck, set defaults, etc on toplevel
property extension properties.
I changed how registration and object initialization works with
respect to properties associated with extensions. Now,
extensions work the same as any other object and code is
cleaner. Property instances associated with registered toplevel
extensions are used to enforce requirements like any other
object.
Added some unit tests specifically for property cleaning for
extensions.
Property order (for those contexts where it matters) is updated
to be spec-defined, toplevel extension, custom.
Remove iterable chaining from CustomObject decorator. If all
values are guaranteed lists now, it no longer makes sense to use
it. Simpler and clearer to use plain old list concatenation.
to v21.common. Custom extensions are not specific to SCOs, so I
don't know why it was in that module. Now, ExtensionDefinition
and CustomExtension are together in the same module, just like
MarkingDefinition and CustomMarking are together. Made sense to
me.
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.
to ReferenceProperty. Add a unit test to ensure that when a
stix2 object is passed as a value of a ReferenceProperty, that
the ID is properly pulled out and used as the actual property
value, and that it doesn't affect the deterministic ID
calculation.
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.
Rich Piazza