[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] JSON DDL suggestions?
- From: "Alessandro Triglia" <sandro@oss.com>
- To: "'Toby Considine'" <Toby.Considine@gmail.com>,<xml-dev@lists.xml.org>
- Date: Wed, 28 Nov 2018 12:18:04 -0500
> -----Original Message-----
> From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby
> Considine
> Sent: Wednesday, November 28, 2018 10:43
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] JSON DDL suggestions?
>
> I am working on a project that demands JSON and whose target is
multi-party
> interoperability.
>
> In the XML world, defining the message exchanges in XSD would be the easy
> win, and there is nothing in this project that would not be handled by any
of
> the versions of XSD.
>
> But this project demands JSON, and the community around the project
> demands JSON. This list has had frequent discussions of XML vs JSON, some
> technical, some tending toward flame, so I am bringing this question here.
>
> What do you see as the most accepted JSON DDL format? Is there any that is
> well accepted by tooling? By well accepted, I mean one that can be
imported
> into an IDE and then guide the programmer to emitting "correct" JSON, and
> that can be used to create pre-validation of messages before consumed by
the
> actual target app.
>
> The potential value of such a DDL has long been discussed.
>
https://www.ietfjournal.org/the-benefits-of-a-json-data-definition-language/
>
> JADN has been suggested, but I see multiple attempts to create a standard
> JADN definition. JXON would suggest using an XSD and moving messages in
> and out of JSON as required.
>
> JSON Schema Validation: A Vocabulary for Structural Validation of JSON
> https://tools.ietf.org/id/draft-handrews-json-schema-validation-01.html
> is still in draft from
>
> JSON Schema and JSON hyper-schema seem not quite done
> https://json-schema.org/
>
> My concern is that I have participated in writing an XML standard (OBIX
1.0) in
> the days before XSD was created. All messages were described by example
> and in prose. Interoperability between implementations was much lower than
> desired. We finally had to go back, and with great effort (1.1) create
schemas
> (XSD) that were compatible with some of the quirks from the original
prose.
>
> In the interests of avoiding a repeat of that experience, what do you
> recommend?
In ASN.1 world, there is a recently published standard that supports JSON:
ISO/IEC 8825-8 | Rec. ITU-T X.697 JSON Encoding Rules (JER)
The standard document can be dowloaded for free from
https://www.itu.int/rec/T-REC-X.697-201710-I/en
You can find a short technical overview of JER at
https://www.oss.com/asn1/resources/asn1-papers/Overview_of_JER.pdf
Essentially, when using this technology you write your "schema for JSON" in
ASN.1 notation, then you apply the JSON Encoding Rules (JER) to produce JSON
text as the "encoding" of your abstract value.
(Recall that ASN.1 is typically used to produce binary encodings in
accordance with BER, DER, PER, or OER. In this case, you will produce JSON
text rather than a binary encoding.)
Obviously, you can also use an existing ASN.1 schema (e.g., one that is
normally encoded in PER) and produce JSON text instead of binary data by
applying the JSON encoding rules.
I have no information about free or open-source tools that support JER at
this time.
Alessandro
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]