Make idref usage easier in python-stix #98

Activity

1. gtback commented on Apr 4, 2014

   

   gtback

   on Apr 4, 2014

   Contributor

   More actions

   To respond to your points:

   1. This is a difficult problem. I tried to work on something similar in python-cybox with caches, and it works ok, but is a bit clumsy. When parsing XML, it depends entirely on the order of the parsing to know whether the "actual" item is in the cache when the "reference" is parsed. The "dereference" operation is a bit clumsy as well, and I haven't thought through it entirely yet. It's also possible to have circular references between items (if each is related to the other), which is another wrinkle in the parsing process.
   2. I would lean towards "no".
   3. For now, I think it makes the most sense for the author to explictly control where it goes, and only include references anywhere else. It's more than typical content authors should need to concern themselves with, but I can't think of a better way.
   4. I've been thinking about a global "validate" function that gets called before items are exported, which could check this and other things that the validator currently does, and some it doesn't (i.e. making sure required elements are there, since the bindings don't enforce them). This could potentially be turned off in the to_xml() function (to_xml(validate=False)). Just a thought.

   An alternative implementation (which I think I would prefer) is to add a "get_reference()" function to the core constructs, which could make the actual line:

   indicator.add_indicated_ttp(ttp.get_reference())

   You could also write a global utilty function that works on any object with id_ and idref properties:

   def make_ref(obj):
       new_obj = obj.__class__()
       new_obj.idref = obj.id_
       new_obj.id_ = None
       return new_obj
   
   indicator.add_indicated_ttp(make_ref(ttp))
2. wbolster commented on Nov 28, 2014

   

   wbolster

   on Nov 28, 2014

   More actions

   Semantically there doesn't seem to be any difference between referencing an internal object and embedding it directly at that point in the tree, or am I mistaken?
3. gtback commented on Dec 1, 2014

   

   gtback

   on Dec 1, 2014

   Contributor

   More actions

   @wbolster: In general, there is no semantic difference. There are a couple nuances, though, discussed here.
4. bworrell commented on Apr 2, 2015

   

   bworrell

   on Apr 2, 2015

   ContributorAuthor

   More actions

   We have begun working on a Cacheable mixin class that handles this, but our initial commits only resolve idref objects. This really needs to handle the coupling of idref and timestamp, so you can easily resolve an object with a given id at a defined timestamp.

   Other considerations

   • Should we allow a user to pass in only an idref to resolve? What's the behavior when more than one object has that id with different timestamp values? Do we return a sequence of objects?
5. bworrell commented on Jun 10, 2015

   

   bworrell

   on Jun 10, 2015

   ContributorAuthor

   More actions

   An approach to making this easier has been implemented in the mixbox branch of python-stix.

   Classes that can be referenced via idref have filter() and get() classmethods, which allow fast lookup of instances by id_ and other properties (timestamp) if needed.
6. gtback

   closed this as completedin #267on Jun 23, 2015