Versioning refinements #458
Conversation
Codecov Report
@@ Coverage Diff @@
## master #458 +/- ##
==========================================
+ Coverage 98.24% 98.25% +0.01%
==========================================
Files 142 142
Lines 15740 15838 +98
==========================================
+ Hits 15463 15562 +99
+ Misses 277 276 -1
Continue to review full report at Codecov.
|
|
I wonder if it is always an error if a type has the revoked property, but not the created property and/or modified property. |
|
I checked the spec (e.g. sections 3.2 and 11.2), but couldn't find anything that put an all-or-nothing requirement on the usage of versioning properties for custom STIX types. E.g. if you use "revoked", you must also use "created" and "modified". It does say "The revoked property is only used by STIX Objects that support versioning...". There is similar description for "modified", but not for "created". That implies a policy which was used by spec authors for spec-defined objects. There is not a "must" or "should" directing creators of custom types to add the other two properties. It would be an odd situation to have a "revoked" property on an object/type you can never revoke, because it's unversionable. I also don't think you're allowed to use properties named the same as common properties for purposes other than what the spec describes(?). So, odd situation but it seems like the spec allows it. Btw, I edited the PR description (updated the behavior bullets). I hadn't quite got the correct behavioral description... maybe that is an indication of how tricky it is to get the logic right :) |
chisholm
force-pushed
the
versioning_refinements
branch
from
bc8fdcd to
ac99e12
Compare
Codecov Report
@@ Coverage Diff @@
## master #458 +/- ##
==========================================
+ Coverage 89.31% 89.33% +0.01%
==========================================
Files 147 147
Lines 16245 16349 +104
==========================================
+ Hits 14509 14605 +96
- Misses 1736 1744 +8
Continue to review full report at Codecov.
|
and dicts, and add better raised exception types if versioning couldn't be done. I changed workbench monkeypatching a bit, to copy some class attributes over to the workbench wrapper class-like callables, since some code expected those attributes to be there (e.g. the versioning code).
chisholm
force-pushed
the
versioning_refinements
branch
from
ac99e12 to
624d71e
Compare
This intended to tighten up versionability detection and plug some holes. It's not perfect, but hopefully an iterative improvement.
The changes include addressing versionability of a type separately from versionability of an object (i.e. an instance of a type). This was kind of blurred before: STIX objects would be checked for presence of versioning properties; dicts would be checked for support from their object type. This presents opportunities for bugs and misleading error messages.
For example, if a custom STIX type were created whose versioning properties were optional, and you didn't provide sufficient properties on an object, you'd get an error that you "cannot create new version of object of this type". That's actually incorrect: you can creation new versions of instances of the type, you just have to provide sufficient properties on the object. Also, if you tried to version a dict of a versionable type, didn't provide an explicit "modified" property for the new version as a kwarg, and it was also missing from the dict, you would get a crash because code just assumed the "modified" property would be in the dict. In the first case, versionability of the object was checked but not the type; in the second case, versionability of the type was checked, but not the object. So both types of error are made.
There is also the question of what to do if someone tries to version a dict of an unregistered STIX type. Without registration, we can't tell what properties the type supports, so we can't determine its versionability. Do we allow versioning?
Behavior included with this PR:
Possible future work: what if neither the type nor instance is considered versionable according to the above criteria, but together, the support/presence criteria are met for versionability? E.g. type supports modified/revoked but not created, and instance has a custom "created" property but has neither "modified" nor "revoked". The type would not be considered versionable, so versionability of the object would not even be considered. But presence of the object's custom "created" property together with the type's support for "modified" and "revoked" put all the ingredients in place for versioning.