spdx-spec
spdx-spec copied to clipboard
spdx
Support for additional properties disabled in JSON schema
As currently written, the JSON schema does not allow for additional properties to accommodate extended vendor-specific data. This appears to be at odds with the SPDX Use Cases 2.0, specifically section 16.1, Communicate data beyond what is described in spec.
Earlier versions of the schema did allow for this behavior, but that feature was disabled in commit a08ffa4.
@kestewart Nothing has changed - as @apmccartney accurately describes, we added restrictions to the JSON schema which limited classes and properties to what was defined in the SPDX spec.
This is consistent with the other schemas.
@apmccartney - the Annotation and comments properties are commonly used to add additional data and support the referenced use case.
That being said, I'm personally open to relaxing the restrictions, but we should discuss this on one of the tech team calls and come to a consensus.
@apmccartney - can you add this to an upcoming tech call agenda at: https://spdx.swinslow.net/p/spdx-tech-minutes and plan to participate in the discussion?
FWIW, my though is that the Extension mechanism is what should be used for additional information about Elements, and the JSON schema should retain "additionalProperties" : false (or in the newer generated schema, "unevaluatedProperties": false). The reason for this is that it signals to users if they mistype a field name, since it will fail schema validation in that case. Otherwise (for non mandatory fields) the error would go unnoticed. Also, it allows us to add more properties to the core objects without needing to worry about conflicting with properties unknown to us added by other parties.
FWIW, my though is that the
Extensionmechanism is what should be used for additional information about Elements, and the JSON schema should retain"additionalProperties" : false(or in the newer generated schema,"unevaluatedProperties": false). The reason for this is that it signals to users if they mistype a field name, since it will fail schema validation in that case. Otherwise (for non mandatory fields) the error would go unnoticed. Also, it allows us to add more properties to the core objects without needing to worry about conflicting with properties unknown to us added by other parties.
Makes sense. @apmccartney - pls. take a look at the Extension class in 3.0 and if that satisfies your use case we can close this issue.
Apologize for my lack communication. I've transitioned employers since initially filing this issue. I'll contact a former colleague who's in a better position to represent my former employer's use case.