Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should manufacture be a property of component, rather than metadata? #346

Closed
nscuro opened this issue Nov 27, 2023 · 6 comments · Fixed by #379
Closed

Should manufacture be a property of component, rather than metadata? #346

nscuro opened this issue Nov 27, 2023 · 6 comments · Fixed by #379

Comments

@nscuro
Copy link
Member

nscuro commented Nov 27, 2023

The majority of fields under metadata refer to the BOM itself.

However, metadata.manufacture technically refers to metadata.component:

"manufacture": {
"title": "Manufacture",
"description": "The organization that manufactured the component that the BOM describes.",
"$ref": "#/definitions/organizationalEntity"
},

This can cause confusion because, as mentioned, everything else refers to the BOM, not metadata.component.

Should manufacture be a property of component instead, to make the association more clear?

@stevespringett
Copy link
Member

IMO, we should likely add manufacturer to component and update the description of manufacture in the metadata section to reflect the BOM. Thoughts @jkowalleck @coderpatros

@coderpatros
Copy link
Member

I agree with that

@jkowalleck
Copy link
Member

add manufacturer to component

we already have component.group for that, right?

The grouping name or identifier. This will often be a shortened, single name of the company or project that produced the component, or the source package or domain name. Whitespace and special characters should be avoided. Examples include: apache, org.apache.commons, and apache.org.


update the description of manufacture in the metadata section to reflect the BOM

Though this would not change the schema, it still would be a change of the meaning of an element. Which would be a breaking change.

@nscuro
Copy link
Member Author

nscuro commented Dec 11, 2023

Though this would not change the schema, it still would be a change of the meaning of an element. Which would be a breaking change.

I agree that this change in semantics could be problematic for BOMs that were generated prior to this.

@stevespringett
Copy link
Member

Is this something we want to address for v1.6?

@jkowalleck
Copy link
Member

jkowalleck commented Feb 8, 2024

IMO, we should likely add manufacturer to component and update the description of manufacture in the metadata section to reflect the BOM. Thoughts @jkowalleck @coderpatros

Sounds good

will open a pullrequest adding the component manufacturer to components.
this is related to #370 (comment)

PS: possible fix here #372 // #379

@jkowalleck jkowalleck linked a pull request Feb 8, 2024 that will close this issue
4 tasks
@jkowalleck jkowalleck linked a pull request Feb 14, 2024 that will close this issue
8 tasks
stevespringett added a commit that referenced this issue Feb 22, 2024
The following changes were made with the intent to not introduce
breaking changes,
neither syntactic nor semantic(!)

## Changes 

- add `component.manufacturer` as "OrganizationalEntity"
  -- fixes #346
- add `component.authors` as list of "OrganizationalContact"
  -- fixes #335
- deprecate `component.author` in favour of `component.authors` and
`component.manufacturer`
- reason: value was described to be a string that could represent
person(s) or organization(s).
    So let's introduce dedicated fields for both of these: 
    Organizations are represented by the new `@.manufacturer` &
    persons are represented by the new `@.authors`.
- add `metatada.manufaturer` as "OrganizationalEntity"
  -- fixes #57
- deprecate `metatada.manufature` in favour of
`metadata.component.manufacturer`
  -- fixes #346


----

## TODO
- [x] update JSON schema
- [x] update XSD
- [x] update protobuff schema
- [x] add examples and test resources

## Follow up tasks
- [ ] update use cases on the Website
- [ ] update SBOM guide
- [ ] create a BC task for 2.0: remove deprecated `metadata.manufacture`
- [ ] create a BC task for 2.0: remove deprecated `component.author`
@jkowalleck jkowalleck mentioned this issue Feb 22, 2024
stevespringett added a commit that referenced this issue Apr 9, 2024
## Added

* Core enhancement: Attestation
([#192](#192) via
[#348](#348))
* Core enhancement: Cryptography Bill of Materials — CBOM
([#171](#171),
[#291](#291) via
[#347](#347))
* Feature to express the URL to source distribution
([#98](#98) via
[#269](#269))
* Feature to express the URL to RFC 9116 compliant documents
([#380](#380) via
[#381](#381))
* Feature to express tags/keywords for services and components (via
[#383](#383))
* Feature to express details for component authors
([#335](#335) via
[#379](#379))
* Feature to express details for component and BOM manufacturer
([#346](#346) via
[#379](#379))
* Feature to express communicate concluded values from observed
evidences ([#411](#411)
via [#412](#412))
* Features to express license acknowledgement
([#407](#407) via
[#408](#408))
* Feature to express environmental consideration information for model
cards ([#396](#396) via
[#395](#395))
* Feature to express the address of organizational entities (via
[#395](#395))
* Feature to express additional component identifiers: Universal Bill Of
Receipts Identifier and Software Heritage persistent IDs
([#413](#413) via
[#414](#414))

## Fixed

* Allow multiple evidence identities by XML/JSON schema
([#272](#272) via
[#359](#359))
  This was already correct via ProtoBuff schema.
* Prevent empty `license` entities by XML schema
([#288](#288) via
[#292](#292))
  This was already correct in JSON/ProtoBuff schema.
* Prevent empty or malformed `property` entities by JSON schema
([#371](#371) via
[#375](#375))
  This was already correct in XML/ProtoBuff schema.
* Allow multiple `licenses` in `Metadata` by ProtoBuff schema
([#264](#264) via
[#401](#401))
  This was already correct in XML/JSON schema.

## Changed

* Allow arbitrary `$schema` values by JSON schema
([#402](#402) via
[#403](#403))
* Increased max length of `versionRange` (via
[`3e01ce6`](3e01ce6))
* Harmonized length of `version` (via
[#417](#417))

## Deprecated

* Data model "Component"'s field `author` was deprecated. (via
[#379](#379))
  Use field `authors` or field `manufacturer` instead.
* Data model "Metadata"'s field `manufacture` was deprecated.
([#346](#346) via
[#379](#379))
  Use "Metadata"'s field `component`'s field `manufacturer` instead. 
  - for XML: `/bom/metadata/component/manufacturer`
  - for JSON: `$.metadata.component.manufacturer`
  - for ProtoBuf: `Bom:metadata.component.manufacturer`

## Documentation

* Centralize version and version-range (via
[#322](#322))
* Streamlined SPDX expression related descriptions (via
[#327](#327))
* Enhanced descriptions of `bom-ref`/`refType`
([#336](#336) via
[#344](#344))
* Enhanced readability of enum documentation in JSON schema
([#361](#361) via
[#362](#362))
* Fixed typo "compliment" -> "complement" (via
[#369](#369))
* Added documentation for enum "ComponentScope"'s values in JSON schema
([#293](#293) via
[`d92e58e`](d92e58e))
  Texts were a taken from the existing ones in XML/ProtoBuff schema.
* Added documentation for enum "TaskType"'s values
([#245](#245) via
[#377](#377))
* Improve documentation for data model "Metadata"'s field `licenses`
([#273](#273) via
[#378](#378))
* Added documentation for enum "MachineLearningApproachType"'s values
([#351](#351) via
[#416](#416))
* Rephrased some texts here and there.

## Test data

* Added test data for newly added use cases
* Added quality assurance for our ProtoBuf schemas
([#384](#384) via
[#385](#385))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants