JSON Schema for PURL?

[chandanbn]

Is there a JSON schema for PURL?

A well defined JSON schema would be able to encode the rules and restrictions on each PURL component in a programmer friendly way. This would enable the use of existing JSON schema validation and manipulation tools in multiple programming languages to create, validate or exchange PURL information. One may also embed or store PURL in a JSON document in a more programmatically accessible format (for eg. with CVE JSON data as on CVElist). This would also help in storing PURL information without the need to parse a PURL on every use (think SQL or NoSQL queries).

The test-suite-data.json seems to contain PURL components encoded as JSON, but is missing scheme, and may not need is_invalid.

  {
    "description": "valid maven purl",
    "purl": "pkg:maven/org.apache.commons/[email protected]",
    "canonical_purl": "pkg:maven/org.apache.commons/[email protected]",
    "type": "maven",
    "namespace": "org.apache.commons",
    "name": "io",
    "version": "1.3.4",
    "qualifiers": null,
    "subpath": null,
    "is_invalid": false
  }

[jdillon]

IMO a JSON schema for PURL isn't super-useful, except for how to define the component parts, but generally the idea of a PURL is to render as a single-line string, so a definition of a JSON schema seems to be generally limited in use.

[stevespringett]

Agreed. JSON schema is completely unrelated to the URI syntax of Package-URL.

[chandanbn]

If I am storing a huge list of PURLs (as in a SBoM) in a database (SQL or NoSQL), I would like to store each purl component in a separate field, (and may be the PURL too). I don't think popular SQL or NoSQL databases are good at directly querying PURL components without some complicated/expensive regex and normalization magic.

Almost all PURL implementations listed here seem to do one or two of:

1. take components as input and construct a PURL,
2. take a PURL and decompose to components.

IMHO the most valuable thing here is a data model of a package locator.
The URI syntax is a serialized version of that data. So is JSON, or XML, or YAML ...
These are like containers, the stuff inside is package locating information. IMHO that information is what matters most, more than the wrapper format.

A well constructed JSON or XML schema essentially takes the prose rules for PURL components and turns them into machine readable rule sets for ease of validation and exchange of the information between systems, databases and tools.

IOW, do you have a formal grammar equivalent of rules for each purl component ?

[stevespringett]

A set of rules in machine readable format would be useful. We are still debating some of them and clarifying others. JSON schema or XML schema would not help us here though.

You can refer to the CycloneDX project which is an SBOM specification that supports PackageURL. You can also look at the Dependency-Track project which can ingest both CycloneDX and SPDX SBOMs.

Support for PackageURL will be included with SPDX v2.2. It was requested on December 2017, but still hasn't made it into the spec yet.