release v1.1 generated json-schema is not valid

[gusfcarvalho]

Describe the bug

The available generated json-schema for OSCAL manifests in release 1.1 refers to draft-7 format - however it refers to both $id and $ref fields on the definition which are only supported from draft-2019 forwards

Who is the bug affecting

Anyone trying to use the release manifests.

What is affected by this bug

Documentation, Metaschema

How do we replicate this issue

1. Download schemas
2. Try to parse it with any json-schema validator

Expected behavior (i.e. solution)

The released json-schema should be compliant to the schema version it refers to.

Other comments

No response

Revisions

No response

[aj-stein-nist]

Hi, @gusfcarvalho, thanks for the report. I will have to understand how you determined that those elements are not part of Draft 7. From quick examination, I was able to find specification elements that confirm they are valid.

To start, if we look at the official site, Draft 7 documents (plural, there are several) and the obsolete version were and continue to be at the IETF site in the section below.

https://json-schema.org/specification-links.html#draft-7

In the core document (the first in that list), I see Section 8.2 specifies $id and Section 8.3 specifies $ref, linked below.

https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-01#section-8.2

https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-01#section-8.3

Am I missing something? Perhaps you can reply with the specific validator and the specifies errors returned? That would be great. If not, I may have to close the issue, thanks again for taking the time to report.

[gusfcarvalho]

from 8.3:

   An object schema with a "$ref" property MUST be interpreted as a
   "$ref" reference.  The value of the "$ref" property MUST be a URI
   Reference.  Resolved against the current URI base, it identifies the
   URI of a schema to use.  All other properties in a "$ref" object MUST
   be ignored.

The problem is with this last bit: All other properties in a "$ref" object MUST be ignored.

Since all other properties in a ref object must be ignored, the $id field must be ignored, meaning they are not valid definitions (no $id to link them back, as this is ignored). This is backed by this issue on json-schema generator for golang: santhosh-tekuri/jsonschema#129

[aj-stein-nist]

OK this clarifies things, thank you very much @gusfcarvalho. We will examine and report back.

[aj-stein-nist]

We need a developer on the team to decide with a review the given usnistgov/metaschema-xslt#74 issue filed and whether its impact to OSCAL developers is important to support one approach to ref and ID in JSON Schema or potentially shut out a variety of common tooling that does not fully conform to the spec and support this hack: after analysis we should be ready to decide if this is blocked until that is worked or we will chose to not work this issue and close it as WONTFIX.

[Arminta-Jenkins-NIST]

At the 9/21 Triage Meeting:

• @nikitawootten-nist agreed to work the issue

[aj-stein-nist]

@nikitawootten-nist, this issue is marked as further analysis need and you volunteered to work on the issue. Are you analyzing/working on analysis for this issue, the upstream metaschema-xslt issue, both?

If analysis is complete and we agree (based on your/others analysis) we cannot work on this issue until the upstream issue is closed and updated, can you mark this as blocked status and/or give us an update on Friday? Thanks.

[Arminta-Jenkins-NIST]

At 9/28 Triage Meeting: @nikitawootten-nist didn't have time to review ticket and will get to it later today or doing next sprint.

[aj-stein-nist]

I volunteered to update status for Arminta backlog refinement on 10/5. I have worked with @nikitawootten-nist to update the current bug reported in metaschema-xslt#74 and have a small module, current JSON Schema generated, and recommended change. I will mark this as blocked until that issue is resolved in the upstream code repo. I have volunteered to work on the code after reporting.

Thanks again to @gusfcarvalho. I had not grokked it so immediately but now I deeply appreciate and understand the problem, I get it now.