Current biblio model in json schema is unusable.

[butler54]

User Story:

As an OSCAL content developer, I need to be able to include data in the bibliography without violating the schema.

Goals:

Within the current schema the specification for what is contained within a biblio element is unbound - e.g. it has not schema.
Within the current schema as rendered in json:

     "biblio" : 
      { "title" : "Bibliographic Definition",
        "description" : "A container in which a set of bibliographic information can included. The model of this information is undefined by OSCAL.",
        "$id" : "#/definitions/biblio",
        "type" : "object",
        "additionalProperties" : false },

the "additionalProperties" : false line effectively constrains the biblio element to not have any data. A quick fix would be to refactor such that "additionalProperties" : true. This is presuming there is no short term intent to put structure on the biblio model.

Dependencies:

I had a search for biblio in the current and past issues and did not find anything hinting at changes. This is not a blocker right now, however, was run into as a special case that needed to be dealt with within automation frameworks.

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[wendellpiez]

This actually appears to be a lapse in the implementation of the JSON Schema generator (that produced the schema in question) running over the Metaschema source.

Metaschema source here has an any element, the effect of which in JSON Schema ought to be to set additionalProperties to be true.

We should confirm that this works properly in M4 Metaschema, and repair (with unit tests) if it does not work.

(We could simultaneously address the handling of Metaschema any in XSD if we want to be thorough.)

@david-waltermire-nist maybe we should fold this into the ongoing testing?

[wendellpiez]

I have lately confirmed that ANY remains to be implemented (on both JSON and XML sides).

Unlike other elements where ANY is stipulated, however, biblio is just a stub - this is why it is presently unusable as Chris describes. (Because we shouldn't have included it at all until we had confirmed all our questions about the ANY feature.)

In other words, as soon as ANY is enabled we should test it in biblio and retire this issue -- and this could be done irrespective of policy questions of where to permit ANY. Presumably the idea of ANY in the context of biblio (an exclusive wrapper) is not as problematic or controversial as ANY inside (for example) part.

So I will proceed to switch on and test out the ANY feature in a working branch, on this assumption.