Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core Schema Draft #10

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

tschmidtb51
Copy link
Contributor

- add a core schema as draft
@sthagen sthagen added tc-discussion Further TC discussion is needed schema labels Jan 24, 2024
- add a shell schema draft
@tschmidtb51
Copy link
Contributor Author

  • add the Shell Schema Draft

@tschmidtb51
Copy link
Contributor Author

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

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

@sthagen
Copy link
Contributor

sthagen commented Apr 9, 2024

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?

Copy link
Contributor

@sthagen sthagen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

- addresses parts of oasis-tcs#10 (review comment from @sthagen)
- correct schema mistake
Copy link
Contributor

@santosomar santosomar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the collaboration @tschmidtb51 and @sthagen , as well as the changes. I approve this version and will propose a motion to the Technical Committee for their approval. We can discuss it in more detail during the next TC meeting.

@santosomar
Copy link
Contributor

santosomar commented May 12, 2024

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 ( #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
Copy link

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 ?

- addresses parts of oasis-tcs#10 (review comment from @sthagen)
- move schemas to reflect intented structure
@tschmidtb51
Copy link
Contributor Author

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

Copy link
Contributor

@sthagen sthagen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@davaya
Copy link

davaya commented May 15, 2024

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.

IM

@tschmidtb51
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema tc-discussion Further TC discussion is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants