[WIP] docs: add testResources JSON `$schema`
- add
$schemato json test resources - fix strict
$schemaenum
part of #254 blocked by #256 supersedes #138
failing tests showed the importance to fix the $schema enum.
Therefore, I plucked #138 via https://github.com/CycloneDX/specification/pull/255/commits/0638f0106f2091ea19e333cbac2c897a44bf8da4
the Java tests still fail.
i assume they do not use the shipped schema files, but the ones found online, or the ones shipped with Java package org.cyclonedx.
how should it be spossible to test the schema against the examples, if the java test do not run on the schema files in this repo? how to test, if the schema files do change? how to test if the schema files in this repo are any good?
The current implementation of JS and PHP uses the files in this repo for validation of the valid/invalid testResources ...
@stevespringett please help.
PS: caused #256
Traditionally, how it's been working is that once changes are made to the schema development branch, those changes are mirrored to the Core Java library and published as a SNAPSHOT release. We keep the snapshots up to date with the latest schemas. It has not been synchronized.
re: https://github.com/CycloneDX/specification/pull/255#issuecomment-1601845304 this will not help this very PR or future PRs that change the schema files, does it? how would you know if the changes affected the tests, before merging them?
Therefore, #256 was created with its acceptance criteria.
Why are there 144 files changed? We cannot accept this PR.
Also, why would test files be required to have the $schema? That makes absolutely no sense.
For example $schema": "http://cyclonedx.org/schema/bom-1.2b.schema.json. If this had been specified for v1.2, we would have had to change all the test files twice (a, and b). We should not have to change existing tests for a bump in schema. That defeats the purpose.
re: https://github.com/CycloneDX/specification/pull/255#issuecomment-1601939004
Also, why would test files be required to have the $schema? That makes absolutely no sense.
Please read #254 to understand the motivation. Then you will see why this makes total sense for the mentioned use case ;-)
If this had been specified for v1.2, we would have had to change all the test files twice (a, and b). We should not have to change existing tests for a bump in schema. That defeats the purpose.
Now you see the hassle everybody goes through who is already referencing the existing schemas files. If we in-place-change the $id in the schema without providing the old version still , users might have to adopt and change existing documents.
The (strict)schema pins its own namespace in downstream documents. To fix this, #138 was introduced but never got accepted.
and now we are where we are.
Why are there 144 files changed? We cannot accept this PR.
Thanks for the heads-up. This PR is a draft, it is in the making, no final solution. There are things to solve first, before I might even continue. Current stage showed issues with the current state of the project:
- some tests run against different schema files (snapshots)
- the need to modify
$schemain a lot of files, because it was modified over the time. In contrast, the XSD does not have this behavior -1.2 stayed the same, even we are at a 3rd iteration of1.2`.
i might rework the content of this PR, and might come up with a followup. goal would be, that the test files for CDX1.6+ will have a schema annotated - as of https://github.com/CycloneDX/specification/issues/402
Superseded by #423