It is recommended to use JSON Schema to define JSON encoding of unified format of BLA-BLA-BLA.
Introduction
Unified format for BLA-BLA-BLA needs a formal protocol definition. For this, a schema definition language should be chosen. A universal schema definition language that can be used to define data structures that can later be expressed using several encoding formats like XML and JSON are preferred. However, this is not a mandatory requirement since industry moves away from XML while JSON adoption grows larger and larger. Thus, support for JSON is mandatory requirement while support for other technologies is optional.
Schema definition language should have good tooling support:
For schema authoring
For data authoring
For validating data compliance to schema (Java)
Schema definition language should have wide adoption in the industry to avoid usage of a dead or rare technology.
IntelliJ IDEA supports JSON and validation by JSON Schema out of the box
Summary
3GPP TS 28.541 uses JSON Schema to define data model.
Very good candidate to describe JSON data format independent of API/RPC/etc. Tooling support is good enough. However, while it is widely adopted, the specification is not yet finalized. This creates a risk that specification might change in incompatible way and schema will have to be adjusted.
Yang
Home
Not found reliable community home
Official learning
Not found
Specification
RFC 6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
RFC 6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content
RFC 6991: Common YANG Data Types [obsoletes RFC 6021]
RFC 7950: The YANG 1.1 Data Modeling Language [replaces RFC 6020]
Is not a data format definition language but API definition language. Requests to allow it to define the data are rejected. Quote: “It's meant to describe APIs, not catalogs of objects that can be used in APIs.” Source: github.com/OAI/OpenAPI-Specificati... While there are technical ways to circumvent this, this is discouraged by language designers. It is risky since the tools are unlikely to support validation once these workarounds are in place.
OpenAPI is based on JSON Schema but has additional restrictions to define APIs. One can be converted to another manually and using specialized tools.
OpenAPI is used to define 3GPP TS 28.532 and TMF 642 APIs.
Due to complexity and restrictions for usage as data format schema rather than API schema, it is recommended to use a better alternative when available.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So what was your choice ?
Schema language for BLA-BLA-BLA unified format
Changes
Executive summary
It is recommended to use JSON Schema to define JSON encoding of unified format of BLA-BLA-BLA.
Introduction
Unified format for BLA-BLA-BLA needs a formal protocol definition. For this, a schema definition language should be chosen. A universal schema definition language that can be used to define data structures that can later be expressed using several encoding formats like XML and JSON are preferred. However, this is not a mandatory requirement since industry moves away from XML while JSON adoption grows larger and larger. Thus, support for JSON is mandatory requirement while support for other technologies is optional.
Schema definition language should have good tooling support:
Schema definition language should have wide adoption in the industry to avoid usage of a dead or rare technology.
JSON Schema
Home
Official learning
Specification
Books
Tooling
Validate sample by schema – build
Validate sample by schema – runtime
Validate sample by schema – support
Schema authoring
Data authoring
Summary
3GPP TS 28.541 uses JSON Schema to define data model.
Very good candidate to describe JSON data format independent of API/RPC/etc. Tooling support is good enough. However, while it is widely adopted, the specification is not yet finalized. This creates a risk that specification might change in incompatible way and schema will have to be adjusted.
Yang
Home
Official learning
Specification
Books
Tooling
Validate sample by schema – build
Validate sample by schema – runtime
Validate sample by schema – support
Schema authoring
Data authoring
Summary
3GPP TS 28.541 uses Yang to define data model.
While Yang model is independent of encoding and Yang supports both XML and JSON, it seems to be a bad choice. The reasons are:
OpenAPI
Home
Official learning
Specification
Books
Tooling
Validate sample by schema – build
Validate sample by schema – runtime
Validate sample by schema – support
Schema authoring
Data authoring
Summary
Is not a data format definition language but API definition language. Requests to allow it to define the data are rejected. Quote: “It's meant to describe APIs, not catalogs of objects that can be used in APIs.” Source: github.com/OAI/OpenAPI-Specificati... While there are technical ways to circumvent this, this is discouraged by language designers. It is risky since the tools are unlikely to support validation once these workarounds are in place.
OpenAPI is based on JSON Schema but has additional restrictions to define APIs. One can be converted to another manually and using specialized tools.
OpenAPI is used to define 3GPP TS 28.532 and TMF 642 APIs.
Due to complexity and restrictions for usage as data format schema rather than API schema, it is recommended to use a better alternative when available.