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.
objects, to structure object_refs type requirements as an empty
blacklist, instead of a whitelist. I think it was originally
necessary due to the older implementation of ReferenceProperty
which was in place at the time. With the implementation change
to invert whitelists with generics to blacklists when
allow_custom=True, a "full" whitelist is internally converted to
an empty blacklist anyway, so it winds up being the same thing.
But I think the full whitelist looks better in the code, so I
prefer that to the empty blacklist.
thought it should, but forgot to fix Report to use
ReferenceProperty in the way I thought it should! Oops.
Added some tests to ensure Report is working property with
custom ID types in object_refs.
Michael Chisholm