You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
itaysk
changed the title
clarifying produce identification
clarifying product identification
May 28, 2024
I believe the
@id
field of product and component needs further clarification.on product id:
on component id:
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:
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):identifiers
field is is described as:From reading the spec alone, one gets the impression that
@id
is optional and used only for references, and thatidentifiers
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 beIf 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)identifiers
, according to examples, and go code)@id
requiredidentifiers
requiredThe text was updated successfully, but these errors were encountered: