ECMA <http://www.ecma-international.org/> International Standards body
developed JavaScript <http://www.ecma-international.org/memento/TC39.htm> to
handle tasks in the browser. They also provided an extension to JavaScript
to develop a lightweight language for interchanging data over the Internet
called JavaScript Object Notation (JSON). The downside of JSON is that it
lacks the capabilities to provide referential integrity. These data models
are neither interoperable nor standardized. Which means, no data
portability. JSON doesn’t provide any ability to resolve name space
ambiguity in which your data is defined, or the structure and data types.
The JSON community has a IETF working draft schema specification
<https://tools.ietf.org/html/draft-zyp-json-schema-04> that would provide a
format for defining the structure of JSON data. This specification would
provide the ability to define validation, documentation, hyperlink
navigation, and interaction control of JSON data. However, this
specification falls short in aligning to and delivering data type primitive
and built-in capabilities that are provided by the W3C body on XML data
standards. There are vendors that publish their own version of JSON schema.
However, these schemas are non-standard and are unable to support
portability between vendors.
The use of JSON in environments that requires interoperability of data
across the enterprise will make governance more challenging. Gartner has
published a white paper called: “Does your NoSQL DBMS Result in Information
Governance Debt?
<https://www.gartner.com/doc/2631833?ref=SiteSearch&sthkw=Nick%20Heudecker&fnl=search&srcId=1-3478922254>”
(subscription required). As technology leaders looking to increase data
integrity and the overall resilience of their enterprise, one can only
conclude that storing data as JSON objects will inhibit you from achieving
these goals.
On Wed, Mar 15, 2017 at 12:26 PM, Wunder, John A. <
jwunder@mitre.org> wrote:
> Just so everyone is aware, we do have JSON Schema for STIX:
>
https://github.com/oasis-open/cti-stix2-json-schemas>
>
>
> *From: *<
cti-users@lists.oasis-open.org> on behalf of Nick Dimiduk <
>
ndimiduk@gmail.com>
> *Date: *Wednesday, March 15, 2017 at 12:53 PM
> *To: *Stuart Maclean <
stuart@apl.washington.edu>
> *Cc: *Greg Back <
gback@mitre.org>, Eyal Paz <
eyalp@checkpoint.com>, "
>
cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>, "
>
cti-users@lists.oasis-open.org" <
cti-users@lists.oasis-open.org>
> *Subject: *Re: [cti-users] Re: Announcing python-stix2
>
>
>
> The python project is great! I've had some luck using the Antlr grammar
> files in a java project of my own. I agree it would be nice to have
> "official" support for more language runtimes. Ideally the tests could be
> refactored such that basic validation verification could be run for all
> target runtimes. I can volunteer some maven incantations to build java
> libraries, if one of the existing authors would like to support the test
> refactoring work.
>
>
>
> Also, as a "Java Programmer", I think JSON is fine. If you need strict
> schema management, validation tools, there's [0].
>
>
>
> [0]:
http://json-schema.org/>
>
>
> On Wed, Mar 15, 2017 at 9:44 AM, Stuart Maclean <
stuart@apl.washington.edu>
> wrote:
>
> On 03/15/2017 09:22 AM, Back, Greg wrote:
>
> Hi Eyal,
>
>
>
> MITRE isn’t working on anything, and I’m not personally aware of anyone
> else who is either. But if someone is, hopefully they’re on one of these
> lists and will respond.
>
>
>
> Greg
>
>
>
> Greg, all,
>
> I have followed the STIX development over the past couple of years, and
> even developed a Java library for STIX manipulation, see
>
https://github.com/uw-dims/stix-java. That was when STIX 1.1 was current.
>
> I watched with some dismay as the XML schema way of doing things in STIX
> 1.1 was dismantled in favor of JSON for STIX 2. While XML schemas are
> complicated, they are very precise, and a document can be checked against a
> schema to assert its validity. Further, the richness of tools for XML
> schemas, notably the JAXB/xjc tools for Java, gives developers a huge
> leg-up in implementing an API for STIX manipulation. I just cranked the
> JAXB handle over the .xsd file set, and hey presto I had a set of Java
> classes with which to start my API.
>
> Going out on a limb here, I also think that Java developers LIKE more
> discipline that Python developers. Static typing vs duck typing? The XML
> schema way of representing information is disciplined, and leads to fewer
> 'You meant X? I thought you meant Y' gotchas at runtime. Extrapolating, I
> think the JSON way of data representation is less disciplined than the XML
> way, hence the natural inclination of Python developers to prefer JSON.
>
> Looking at the STIX 2 specs, I admire effort the authors must have put
> in. But from a library builder's point of view, there being no
> machine-ingestable docs (ie the xsd files in STIX 1.1), I am back to square
> one (if I have missed any machine-readable docs, I apologize).
>
> So, in a nutshell, my own feeling is that there will be no Java-language
> STIX 2 manipulation tools, a sad fact, and I sincerely hope I am wrong in
> this respect. I do know that I won't add to my STIX 1.1 Java effort.
>
> Stuart
>
>
>