"version": 1 } 2 { Consumer updates example "type": "example", object because the received "id": "example--1", version number is higher than "created": "2016-05-01T06:13:14.000000Z", the object that is currently stored. "modified": "2016-05-08T03:43:44.000000Z", "version": 4 } 3 { Consumer ignores this object "type": "example", because they already have a "id": "example--1", newer version of the object. "created": "2016-05-01T06:13:14.000000Z", Note: consumer might choose to "modified": store meta-information about "version": 3 received objects, including } versions that were received 4 { Consumer deletes example "type": "example", object, but keeps some metadata "id": "example--1", regarding the object. "created": "2016-05-01T06:13:14.000000Z", "modified": "version": 12, "revoked": true } 5 { Consumer ignores this object "type": "example", because they already have a "id": "example--1", newer version of the object (the "created": "2016-05-01T06:13:14.000000Z", revoked version). "modified": "2016-05-10T17:28:54.000000Z", "version": 11 } Example Object Creator Workflow This section describes an example workflow where a object creator publishes multiple updates to a particular object. This scenario assumes a human using a STIX implementation. (In this example, the STIX Objects have been truncated for brevity.) Step # STIX Object User Action 1 N/A STIX is not involved in this scenario. User clicks a create – button in the user interface, creates a (Tools could choose to create and track STIX versions SDO, then clicks save. for internal changes, but it is not required by the This action causes specification.) information to be stored in the product’s database.
"version": 1 } 2 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "2016-05-08T03:43:44.000000Z", "version": 4 } Consumer updates example object because the received version number is higher than the object that is currently stored. 3 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "version": 3 } Consumer ignores this object because they already have a newer version of the object. Note: consumer might choose to store meta-information about received objects, including versions that were received 4 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "version": 12, "revoked": true } Consumer deletes example object, but keeps some metadata regarding the object. 5 { "type": "example", "id": "example--1", "created": "2016-05-01T06:13:14.000000Z", "modified": "2016-05-10T17:28:54.000000Z", "version": 11 } Consumer ignores this object because they already have a newer version of the object (the revoked version). Example Object Creator Workflow This section describes an example workflow where a object creator publishes multiple updates to a particular object. This scenario assumes a human using a STIX implementation. (In this example, the STIX Objects have been truncated for brevity.) Step # STIX Object User Action 1 N/A – STIX is not involved in this scenario. (Tools could choose to create and track STIX versions for internal changes, but it is not required by the specification.) User clicks a create button in the user interface, creates a SDO, then clicks save. This action causes information to be stored in the product’s database.
STIX2.0-draft3-core.docx