Core Schema Draft

[tschmidtb51]

• add a core schema as draft
• alternative suggestion to #8

[tschmidtb51]

• add the Shell Schema Draft

[tschmidtb51]

The taxonomy (as mentioned in #11) would go into the enums of the core schema:

"enum": ["EndOfLife", "EndOfSupport"]

[sthagen]

Assuming that the URLs to both schema files "work", a valid, albeit very old and dusty, instance that validates against the shell schema (using my path separated and compressed reference URLs) would be the following:

{
  "$schema": "https://docs.oasis-open.org/openeox/tbd/schema/shell.json",
  "statements": [
    {
      "core": {
        "$schema": "https://docs.oasis-open.org/openeox/tbd/schema/core.json",
        "last_updated": "1573-04-28T12:08:26Z",
        "status": [
          {
            "category": "EndOfLife",
            "timestamp": "tba"
          },
          {
            "category": "EndOfSupport",
            "timestamp": "1957-07-30T15:40:30Z"
          }
        ]
      },
      "productName": "foo bar baz",
      "productVersion": "2024.4.9",
      "supplierName": "quux"
    }
  ]
}

Right?

Does that look like we expect such an instance to look?

Bonus question:

Given the ambiguous practice of EOS - where the meaning of the S is unclear to many: Should we add an acronym field inside the status object items (or separate glossary like object) to allow the producer annotating their semantic field with their marketing language?

[santosomar]

Motion link: https://groups.oasis-open.org/discussion/motion-to-merge-pull-request-10

I hereby submit the following motion and request that if seconded and no objection received per this list before one week has passed on 2024-05-18 23:00 UTC to automatically carry. We will state the result via an mail to this list when the period has passed.

I, Omar Santos, move to approve the pull request ( https://github.com/oasis-tcs/openeox/pull/10) which contains our initial core schema draft. By merging this pull request, we will facilitate the schema review during our monthly calls and working meetings.

[shridarc]

Two thing we need to clarify: 1) Should we say the Schema field are mandatory, and each supplier can add their own field 2) Should there be one line field defination in schema template or link to schema will provide ?

[tschmidtb51]

Two thing we need to clarify: 1) Should we say the Schema field are mandatory, and each supplier can add their own field 2) Should there be one line field defination in schema template or link to schema will provide ?

This is something to discuss in the TC. However, the schema must be as fixed that consumers can use it. If suppliers need additional field (taking about "need" not about "want"), we did something wrong in our standard

[davaya]

Under the email discussion of this pull request, Duncan suggested consideration of OpenC2's JADN as a schema language. As the author of JADN, I believe there is some misunderstanding of the purpose of an EoX schema. IMO, this TC's choice of JSON as a data exchange language and JSON Schema its data model is entirely justifiable.

OpenC2, and the new Open Supplychain Information Modeling (OSIM) TC, have a different purpose: to define an abstract schema that supports messaging in multiple data formats using different data models derived from a common information model. If EoX ever considers data formats other than JSON, or performance-optimized JSON/CBOR encodings, or documentation-as-code tables that directly generate the message schema, an information model may be of interest in the future.

[tschmidtb51]

Under the email discussion of this pull request, Duncan suggested consideration of OpenC2's JADN as a schema language. As the author of JADN, I believe there is some misunderstanding of the purpose of an EoX schema. IMO, this TC's choice of JSON as a data exchange language and JSON Schema its data model is entirely justifiable.

Thank you for the clarification. Having read through your explanation, I think the JSON schema is the right choice for us.