Establish best practices for use of the x_ fields

[david-waltermire]

The QWG needs to determine what the best practices are for use of the x_ fields. This may involve providing a means to get a JSON schema for the field and/or any associated documentation provided by the declaring CNA.

Schema validation could be supported as follows.

{ "x_foo": {
  "$schema": "schema URL",
  .. data
  }
}

Possible options need to be discussed to come up with a way forward. Please share thoughts in the discussion below.

[alilleybrinker]

See also:

• Drop support for optional data values starting with "x_" #318
• Move "x_generator" to an official and optional string value "generator" #327

If this does happen, it could be part of the GitHub Pages site. See:

• Consider creating a GitHub Pages site for CVE Record Format documentation #432
• Use Docusaurus for docs site #446

[zmanion]

Note that the SADP pilot plans to use some 'x_' fields: https://github.com/CVEProject/sadp-pilot/blob/main/CVE-2025-14174_sadp.json.

We're open to alternatives, but I don't know what those are. If SADP continues into production, any necessary (and tested) 'x_' fields would be made part of the schema.

[zmanion]

Re-reading the top of this issue, the SADP pilot could define and reference (S)ADP schema so that 'x_' fields would be self-defining.

Also the SADP pilot should try to define any new/needed fields with ADP-wide scope, e.g., x_adpSomething with "adpType": "sadp" instead of x_sadpSomething.