[fdt] Another FDT candidate

David Kemp <dk190a@gmail.com> Wed, 26 August 2020 17:58 UTC

MIME-Version: 1.0
From: David Kemp <dk190a@gmail.com>
Date: Wed, 26 Aug 2020 13:58:41 -0400
Message-ID: <CAE5tNmpNKFmFBRLuDAsOZ5Gk3wouMVdxuFLSXSAUVFLzgEXDNA@mail.gmail.com>
To: fdt@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008790a005adcb922f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/fdt/SDSzbNErDVYrBSIOsjzmE5mqsIo>
Subject: [fdt] Another FDT candidate
Precedence: list

Hi Marc,

I am working on a new PDU description language.  It:
* is abstract in that it separates type definitions from
serialization/encoding
* is targeted at the full spectrum of structured data formats from XML to
JSON to CBOR to schema-required binary formats such as
Protobuf/Thrift/Avro/etc to bare-bones bits in boxes like RFC 791.  It is
not targeted at text formatting like regular expressions or xBNF.
* supports distributed development with namespaces and short namespace
prefixes
* is itself a structured data object that can be serialized and sent with
the data it describes

Every type definition is a 5-tuple with a fixed format that can be
represented graphically as an entity in an ERD or textually in the
language's IDL. In the database modeling hierarchy of conceptual, logical
and physical, it is a fourth category, "physical information model", lying
between the logical model and the physical data model.

It's purpose is to both 1) translate between concrete PDU description
languages (e.g. RELAX <--> JSON Schema <--> CDDL), and 2) translate between
concrete PDUs (XML <--> JSON <--> CBOR).  It's advantage is that its
translation rules can be fit for purpose. JSON protocols typically define
everything as maps and developers are enormously resistant to using
anything else. As a result, JSON data typically gets translated to CBOR
data that is anything but concise.
Using an information model allows developers to have their cake and eat it
too.  For example, ISO 3166 country definitions can be represented as maps
in JSON but as arrays in databases, spreadsheet CSVs, and CBOR.

The latest draft of the specification is available from
https://github.com/oasis-tcs/openc2-jadn/tree/working. (Because it is not a
standard the GitHub base branch is empty - be sure to look in the working
branch.) Feedback on the draft itself, as well as suggestions for how and
what venue to use for its maturation, are welcome.

Regards,
David

From: Marc Petit-Huguenin <petithug@acm.org>
> <&lt;petithug@acm.org&gt;>Date: Fri, Jun 12, 2020 at 10:03 AM
> Hi Scott,

I still find your terminology confusing. I am not sure if you are
> proposing to design a new PDU description language (ala ASN.1, ABNF, RBNF,
> CDDL, XML RELAX, etc..) or a new structured PDU format (ala DER, BER, XML,
> JSON, CBOR, etc...). If it is the former, I would suggest to resend your
> email to fdt@ietf.org, where we discuss this kind of things. Thanks.

[fdt] Another FDT candidate David Kemp