[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]
> I've never seen a widely implemented RFC that had multiple different types of possible bindings in it (XML, JSON, other) for a data interchange format standard. Is there an example of this? I'd like to see how it was approached.
Jason, I have asked the same question to myself. I like the “mandatory” default format option as it keeps me from having to debate single format vs multiple format within the group. Personally, I would really enjoy a single format.
I also ask the group, are there any widely adopted standards that use multiple data exchange formats?
Aharon
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead
Date: Wednesday, September 16, 2015 at 8:06 AM To: "Grobauer, Bernd" Cc: "jwunder@mitre.org", "cti@lists.oasis-open.org" Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion] RE Schema, JSON Schema exists and is codified in an IETF draft RFC -
http://json-schema.org/. Hi, here is a little picture that captures some of the concepts contained in John's email (I have added something I call 'translations' to the picture, because I think we may need them): The questions below have been touched upon here and there in various emails on the various lists: I feel it is important to restate them in a structured way, so that we consider them all when choosing HLM and MTI binding: 1) What is our requirement on how the 'derive from' relation comes about? Do we require an automated or semi-automated process? We are talking about very sizable models, so a completely manual process will pose some challenges. My current feeling is that if no HLM-MTI-pair with an at least semi-automated process can be found, then the nature of the HLM is documentation rather than 'ground truth' and we should think twice about spending effort for a HLM which we then transform by hand into a binding. Without an HLM, the MTI-binding would have to serve as HLM, as is the case with XSD in the pre-OASIS MITRE standards. 2) What is our requirement on how the MTI binding is actually defined? I would argue that some kind of schema definition is required and "definition by code" is not sufficient. So, with XML we have XSD. It seems there are schema-definition schemes for JSON, but I do not know how powerful/stable/universally-accepted these are, nor what the status regarding item 3) below is. 3) How much automated support for deriving an API for the MTI binding do we require? Obviously, we need APIs to produce/consume content in the binding(s). Especially for the MTI, we should think about how much automated support we require for producing an API for a given binding. Currently, MITRE's STIX/CybOX APIs are based on automated mechanisms that turn XSDs into Python code for parsing and generating XML conforming to the XSD. Given the size of the models we are contemplating, writing an API from scratch might be quite a bit of effort. 4) What are our requirements regarding translations between the MTI binding and alternative bindings? Without some kind of executable translation between two bindings, there is a danger that the standard becomes fragmented, because a system supporting one binding may not be able to interpret data that is available in some other binding. Of course, this problem could be solved "by policy", stating that each OASIS-CTI-compatible system must support the MTI binding (thus forcing the implementors who work with an alternative binding to also implement a translation fromt/to the MTI), but the danger remains that we suddenly have systems that exclusively speak an alternative binding. So maybe there should be a requirement that an "official" alternative binding must be supported by a reference implementation that translates from/to that binding into the MTI binding? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]