[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]
Hi Jason/all,
Good points from both you and Bernd. I have a few thoughts:
- To your last question, I was personally wondering about whether there were any cases where there was a widely implemented standard with different bindings. I asked Sean (Barnum) about it, and he helpfully pointed me to two OASIS specifications: XACML
(which has a JSON profile) and OData. OData in particular does seem to have several bindings on equal footing (notably ATOM and JSON). If anyone else knows of any I think it would be helpful to point us to them so we can see how they approached the binding
phase (and the modeling phase, to be honest).
- I share your concern about automatically generating the bindings, but I think the approach would not be to fully automate it but to define a set of rules that you follow to manually or semi-automatically convert it. This is the approach you’ll see in
STIX 1.2.1. So, for example, if you have a “list” in the high-level model, in XML you might translate it as <ListItems><ListItem/><ListItem/><ListItem/></ListItems> while in JSON you would use [{item},{item},{item}]. This should allow us to define bindings
that correctly follow the design patterns of the binding format (nobody wants XML patterns in JSON or JSON patterns in XML) while still deriving off of the same high-level model and therefore staying semantically compatible. To Bernd’s point #1, while this
manual process would be time-consuming, ideally we only need to do it every so often. We could probably also write some ad-hoc scripts to at least semi-automate it, even if we don’t use off-the-shelf support for generating bindings.
- This is my personal opinion, but to me the strongest case to defining an alternate binding is a binary encoding. XML and JSON solve similar use cases but a binary encoding like what Trey has proposed might be a good alternate for high-scale, high-volume
use cases where even serializing to JSON is too large or slow. That said, allowing either XML or JSON as an alternative binding (presuming one will be the MTI binding, which may not be the case) shouldn’t have huge ecosystem compatibility implications assuming
that the MTI specification is implemented as well (at least on external interfaces).
- I share the concern about creating incompatibilities in the ecosystem, as I’ve expressed before. The intent of the MTI specification is to serve as the lingua franca…while tools could of course choose to only implement an alternative protocol, by having
the MTI binding literally be _mandatory_ to claim full compliance with STIX (or CybOX or TAXII) I think we can mitigate those concerns. Users of alternative bindings would either have to support the MTI specification or be very clear that they’re not compatible
with it. I believe (and people from OASIS can correct me if I’m wrong) that we can define these rules when we write the conformance sections of the documents.
- To Bernd’s point #3, it’s my opinion that as we simplify and improve the model itself as well as how it’s expressed in the binding format (even if we stick to XML as the MTI spec, we can use simpler XML), the need for things like python-stix should decrease.
While we definitely still want to have them, one of the nice thing about a lot of popular formats is that they’re easy enough to use “raw”. When I worked with the Twitter or Facebook APIs (in my previous life at a startup) I didn’t need code-level bindings
(what we call APIs) because the JSON and XML formats were easy to work with natively. I think if we get to that point for STIX/CybOX (while not losing support for important use cases of course) we’ll have done a great job. As a side effect, that would also
make generation of code-level bindings even easier.
John
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead
Date: Wednesday, September 16, 2015 at 8:06 AM To: Bernd Grobauer Cc: "Wunder, John A.", "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]