On yesterday’s CTI TC working call Sean Barnum represented some of our concerns related to the non-URI Object-ID proposal pulled together by John Wunder, namely a concern that it may make other serializations like
JSON-LD unworkable. After some experimentation and a little tweaking of John Wunder’s proposed workaround to allow for language bindings such as JSON-LD to not be prohibited, I’ve been able to come up with something that looks like it should work.
So based on my findings, I can support that this approach DOES NOT PROHIBIT support for other language bindings, such as JSON-LD, where IRI/URI is
For those of you who may be interested in how the workaround works to make non-IRI/URI object IDs in JSON-LD here is a brief description. This approach even removes the need for the additional “@id” and “@type”
lines on every object.
The changes I had to make was to tweak the “@context” statement as follows:
“id”: “@id”, // this aliases id so there is no @id required per object
// this aliases type so there is no @type required per object
The only ‘gotcha’ I encountered is an issue with the use of “:” and “::” as they are reserved in IRI/URI processing, so I had to change the proposed use of “::” to “--“. It looks like John has made this same change
to the proposal as well.
With these changes, a STIX document compliant with JSON MTI need only to have the “@context” statement (shown in red) added at the top of the file in order to be treated correctly as a JSON-LD document.
"name": "Jane Doe",
"jobTitle": "Bad Guy",
"telephone": "(425) 123-4567"
As a side note, I’ve not seen a statement about what the appropriate behavior should be when a JSON MTI compliant consumer receives a document with a field it doesn’t understand (maybe due to a typo or somebody tried to make a private extension). But if the
specified behavior was to ignore the field rather than fail the processing of the entire document, then under the situation where a JSON-LD language binding document was inadvertently sent to a consumer that only excepts JSON MTI language binding, the behavior
would still allow the document to be processed as a compliant JSON MTI document since the @nodes and @fields would be ignored or skipped.