Information Model example

[davaya]

Initial cut at an EoX information model derived from the proposed JSON Schema, intended to illustrate some of the ways an IM can be used. Contains core and shell packages, and a single bundle shell-resolved package containing both.

[tschmidtb51]

@davaya Thank you for your contribution and work to convert the draft schemas. Out of curiosity: Is there any specific tool you used for that or was that done manually?

[tschmidtb51]

As stated in https://github.com/oasis-tcs/openeox/pull/10#issuecomment-2178942840, I still think choosing a JSON schema is way to go for us. (However, that is the Editors / TC's decision.)

[santosomar]

For the purpose of the TC discussion and to provide additional context:

• JADN is a schema language used to describe and validate the structure and constraints of JSON data. It is not a data interchange format itself, but a way to define the rules that JSON data must follow.
• JSON data consists of key-value pairs, arrays, and nested objects. It represents data in a simple, hierarchical structure.
• JADN defines the schema for JSON data, specifying data types, required fields, optional fields, and constraints. It provides a more formal definition of the data structure compared to JSON.

The pros and cons that I see on the traditional JSON schema are:

• JSON Schema is widely adopted and supported by many tools and libraries across different tools and libraries, although JADN is catching up. JADN is less widely adopted compared to JSON Schema, which means fewer tools and libraries might support it.
• The traditional JSON schema also has extensive community support and documentation make it easier to find resources, examples, and help when needed.
• However, the traditional JSON Schema can become super confusing for more complex data models, which might make it harder to read and maintain. JADN provides detailed data modeling capabilities, including the ability to define complex types and constraints. It can provide a clearer and more structured definition of data, making it easier to understand the expected data format and constraints. In this case our schema is not that complex (yet).

So my question is, why not have both available since a lot of the work has already been done by @davaya ?

[santosomar]

We discussed this in the TC meeting on 2024-06-19. The TC suggested that starting with the traditional JSON schema may be the best approach. Due to the OASIS system not being able to calculate quorum automatically, a motion will be sent via email.

[santosomar]

https://groups.oasis-open.org/discussion/motion-for-openeox-to-use-the-traditional-json-schema-not-include-jadn-for-now#bmf137b8ef-8702-43c5-96ec-ace8694b9dba