Description
I believe the @id
field of product and component needs further clarification.
on product id:
The optional @id field takes an IRI to make the product referenceable inside the document and addressable externally.
on component id:
Optional IRI identifying the component to make it externally referenceable.
According to this, the only use case mentioned for @id
is for reference-ability, no mention of using this field for product identification.
It does mention that id CAN be a purl, but it reads as it's still only for references:
As Package URLs are valid IRIs, the @id can take a purl as a value.
This interpretation is further confirmed since purl is one of many allowed identifiers.
For the use case product identification (actually specifying the affected software), the spec only mentions the identifiers
fields (also vaguely):
The spec provides an expressive product struct with fields to address the product using identifiers, hashes.
identifiers
field is is described as:
A map of software identifiers where the key is the type and the value the identifier.
From reading the spec alone, one gets the impression that @id
is optional and used only for references, and that identifiers
should be used to specify the affected product.
However, all the examples are using @id
exclusively for product identification, as well as vexctl-create tool.
My understanding is that the spec authors intent was that @id
would be
- reference-able IRI
- if using purl, also the product identifier
If that's correct, I suggest updating the spec to clarify:
@id
CAN be used to identify product (in addition to being used as reference IRI)- but only if the identification is using purl?
- in this case, it seem to be the preferred way (over
identifiers
, according to examples, and go code)
- in which of the use cases is
@id
required - in which of the use cases is
identifiers
required
Activity