was begun by frank7y. Added some unit tests.
Also address a design flaw which prevented the AST builder
function create_pattern_object() from honoring module_suffix
and module_name parameters after the first call.
DNF transform could trigger an error from the AST code which
does the SCO type checks on comparison expression ANDs. The
transform had been ignoring SCO types. Now, it will catch
the exception and drop the AND from the pattern. Added a
couple new unit tests for this.
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.
- Change CS 02 reference to CS 03
- Fix typos
- Remove the extension definition from the first example.
It's not relevant. Change the explanation to explain the
real reason why that example works: if unregistered toplevel
property extensions are present, the library lets unrecognized
toplevel properties pass.
- Change the explained rationale for registering an extension.
It had described "repetitive instantiation" of an extension, but
I think it was referring to an extension definition, and that is
not what happens. The benefit of registration is that the library
will know which properties are associated with the extension and
can enforce their requirements. Changed the commentary to explain
this.
- Fix the custom marking example to not use the @CustomMarking
decorator. It is no longer used for extension-based custom
markings. Instead, it just shows a normal extension being
registered and applied to a marking-definition. The commentary
is changed to explain this too.
Chris Lenk