Remove example collection URLs from the CVE schema file

[darakian]

Kicking up a minimal PR to make the schema file itself a little easier to parse (for a human). The examples seem like they are not relevant for a machine, but please correct me if I'm wrong in that assumption. Open to changing where the documentation for the examples goes, fleshing out the new markdown file more, or whatever else seems like a good idea prior to merging this PR. Let me know what you all think and/or if this is a bad idea and we can close it out without merge too :)

[mprpic]

While the examples are not overly useful in the schema itself when used for validation, the browseable web UI version of the schema is quite readable for a human and probably benefits from having the examples listed: https://cveproject.github.io/cve-schema/schema/docs/#oneOf_i0_containers_cna_affected_items_collectionURL

I personally would prefer to keep the examples within the schema.

[darakian]

Interesting. I guess that webui is generated from the schema file itself?

[mprpic]

@darakian Correct: https://github.com/CVEProject/cve-schema/blob/main/schema/support/docs/docs.sh#L3

[darakian]

I see. Sorry I wasn't aware. Do you think this PR might still be worth discussing as a reduction in the number of examples instead of outright removing the full set?

[mprpic]

@darakian I think it's important to have the full set somewhere (doesn't have to be in schema examples, I suppose), but what I would actually prefer to have is a mapping of collectionUrls to purl types to get rid of the "yet another way to identify component types" nature of these URLs.

[darakian]

I would actually prefer to have is a mapping of collectionUrls to purl types

Is that even possible? collectionUrls seem to just be arbitrary urls as far as I can tell.

[mprpic]

@darakian I don't see it as something enforceable by a schema (unless we truly switch to purl-based component identification), more of a side mapping. And while it is a relatively random collection of URLs, you can note that most of them relate to specific package types and specific package indexes or vendors that publish them.

[darakian]

I don't see it as something enforceable by a schema

Not sure I follow. Are you saying that the mapping of collection urls to purls can't be enforced or something else?

And while it is a relatively random collection of URLs, you can note that most of them relate to specific package types and specific package indexes or vendors that publish them.

Most is not all though. Having a long list of example arbitrary urls is a bit strange to me.

fwiw I understand the value of a collection url to be something for a human who when given the (url, id) tuple will be able to make sense of it. Please correct me if I'm wrong in that understanding.

[Makotogew]

Thx