[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Capturing Today's Call & Other topics
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
required.
Based on this I offer my support for the proposed solution at https://github.com/STIXProject/specifications/wiki/Proposal:-IDs-should-be-UUIDs.
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:
"@context": {
"@base": "http://example.com/“,// this provides the default IRI/URI prefix
"@vocab": "http://oasis-open.org/cti/stix/“,// this sets default namespace s
“id”: “@id”, // this aliases id so there is no @id required per object
“type”: “@type”
// 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.
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.
Paul Patrick
Chief Architect
iSIGHT Partners
From: <cti@lists.oasis-open.org> on behalf of Mark Davidson <mdavidson@soltra.com>
Date: Tuesday, January 26, 2016 at 12:21 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: [cti] Capturing Today's Call & Other topics
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]