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
Copy file name to clipboardExpand all lines: schema/bom-1.6.proto
+17-16Lines changed: 17 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -106,7 +106,7 @@ message Component {
106
106
optionalstringgroup=7;
107
107
// The name of the component. This will often be a shortened, single name of the component. Examples: commons-lang3 and jquery
108
108
stringname=8;
109
-
// The component version. The version should ideally comply with semantic versioning but is not enforced. Version was made optional in v1.4 of the spec. For backward compatibility, it is RECOMMENDED to use an empty string to represent components without version information.
109
+
// The component version. The version should ideally comply with semantic versioning but is not enforced. Version was made optional in v1.4 of the spec. For backward compatibility, it is recommended to use an empty string to represent components without version information.
110
110
stringversion=9;
111
111
// Specifies a description for the component
112
112
optionalstringdescription=10;
@@ -139,7 +139,7 @@ message Component {
139
139
optionalReleaseNotesreleaseNotes=24;
140
140
// A model card describes the intended uses of a machine learning model, potential limitations, biases, ethical considerations, training parameters, datasets used to train the model, performance metrics, and other relevant data useful for ML transparency.
141
141
optionalModelCardmodelCard=25;
142
-
// This object SHOULD be specified for any component of type `data` and MUST NOT be specified for other component types.
142
+
// This object SHOULD be specified for any component of type `data` and must not be specified for other component types.
143
143
optionalComponentDatadata=26;
144
144
// Cryptographic assets have properties that uniquely define them and that make them actionable for further reasoning. As an example, it makes a difference if one knows the algorithm family (e.g. AES) or the specific variant or instantiation (e.g. AES-128-GCM). This is because the security level and the algorithm primitive (authenticated encryption) is only defined by the definition of the algorithm variant. The presence of a weak cryptographic algorithm like SHA1 vs. HMAC-SHA1 also makes a difference.
145
145
optionalCryptoPropertiescryptoProperties=27;
@@ -149,9 +149,9 @@ message Component {
149
149
repeatedOrganizationalContactauthors=29;
150
150
// Textual strings that aid in discovery, search, and retrieval of the associated object. Tags often serve as a way to group or categorize similar or related objects by various attributes. Examples include "json-parser", "object-persistence", "text-to-image", "translation", and "object-detection".
151
151
repeatedstringtags=30;
152
-
// Specifies the OmniBOR Artifact ID. The OmniBOR, if specified, MUST be valid and conform to the specification defined at: https://www.iana.org/assignments/uri-schemes/prov/gitoid
152
+
// Specifies the OmniBOR Artifact ID. The OmniBOR, if specified, must be valid and conform to the specification defined at: https://www.iana.org/assignments/uri-schemes/prov/gitoid
153
153
repeatedstringomniborId=31;
154
-
// Specifies the Software Heritage persistent identifier (SWHID). The SWHID, if specified, MUST be valid and conform to the specification defined at: https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
154
+
// Specifies the Software Heritage persistent identifier (SWHID). The SWHID, if specified, must be valid and conform to the specification defined at: https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
// A model card describes the intended uses of a machine learning model, potential limitations, biases, ethical considerations, training parameters, datasets used to train the model, performance metrics, and other relevant data useful for ML transparency.
281
281
EXTERNAL_REFERENCE_TYPE_MODEL_CARD=32;
282
-
// Plans of Action and Milestones (POAM) complement an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
282
+
// Plans of Action and Milestones (POA&M) complement an "attestation" external reference. POA&M is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
283
283
EXTERNAL_REFERENCE_TYPE_POAM=33;
284
284
// A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations.
// Specifies the details and attributes related to a software license. It can either include a valid SPDX license identifier or a named license, along with additional properties such as license acknowledgment, comprehensive commercial licensing information, and the full text of the license.
378
379
messageLicense {
379
380
oneoflicense {
380
-
// A valid SPDX license ID
381
+
// A valid SPDX license identifier. If specified, this value must be one of the enumeration of valid SPDX license identifiers defined in the spdx.schema.json (or spdx.xml) subschema which is synchronized with the official SPDX license list.
381
382
stringid=1;
382
-
// If SPDX does not define the license used, this field may be used to provide the license name
383
+
// The name of the license. This may include the name of a commercial or proprietary license or an open source license that may not be defined by SPDX.
383
384
stringname=2;
384
385
}
385
386
// Specifies the optional full text of the attachment
@@ -704,7 +705,7 @@ message Composition {
704
705
repeatedstringdependencies=3;
705
706
// The bom-ref identifiers of the vulnerabilities being described.
706
707
repeatedstringvulnerabilities=4;
707
-
// An optional identifier which can be used to reference the composition elsewhere in the BOM. Every bom-ref MUST be unique within the BOM.
708
+
// An optional identifier which can be used to reference the composition elsewhere in the BOM. Every bom-ref must be unique within the BOM.
708
709
optionalstringbom_ref=5;
709
710
}
710
711
@@ -767,7 +768,7 @@ message EvidenceMethods {
767
768
}
768
769
769
770
messageEvidenceOccurrences {
770
-
// An optional identifier which can be used to reference the occurrence elsewhere in the BOM. Every bom-ref MUST be unique within the BOM.
771
+
// An optional identifier which can be used to reference the occurrence elsewhere in the BOM. Every bom-ref must be unique within the BOM.
771
772
optionalstringbom_ref=1;
772
773
// The location or path to where the component was found.
773
774
stringlocation=2;
@@ -818,7 +819,7 @@ message Note {
818
819
}
819
820
820
821
messageReleaseNotes {
821
-
// The software versioning type. It is RECOMMENDED that the release type use one of 'major', 'minor', 'patch', 'pre-release', or 'internal'. Representing all possible software release types is not practical, so standardizing on the recommended values, whenever possible, is strongly encouraged.
822
+
// The software versioning type. It is recommended that the release type use one of 'major', 'minor', 'patch', 'pre-release', or 'internal'. Representing all possible software release types is not practical, so standardizing on the recommended values, whenever possible, is strongly encouraged.
822
823
stringtype=1;
823
824
// The title of the release.
824
825
optionalstringtitle=2;
@@ -1072,7 +1073,7 @@ message AnnotatorChoice {
1072
1073
}
1073
1074
1074
1075
messageAnnotation {
1075
-
// An optional identifier which can be used to reference the annotation elsewhere in the BOM. Every bom-ref MUST be unique within the BOM.
1076
+
// An optional identifier which can be used to reference the annotation elsewhere in the BOM. Every bom-ref must be unique within the BOM.
1076
1077
optionalstringbom_ref=1;
1077
1078
// The object in the BOM identified by its bom-ref. This is often a component or service but may be any object type supporting bom-refs.
1078
1079
repeatedstringsubjects=2;
@@ -1085,7 +1086,7 @@ message Annotation {
1085
1086
}
1086
1087
1087
1088
messageModelCard {
1088
-
// An optional identifier which can be used to reference the model card elsewhere in the BOM. Every bom-ref MUST be unique within the BOM.
1089
+
// An optional identifier which can be used to reference the model card elsewhere in the BOM. Every bom-ref must be unique within the BOM.
1089
1090
optionalstringbom_ref=1;
1090
1091
// Hyper-parameters for construction of the model.
1091
1092
optionalModelParametersmodelParameters=2;
@@ -1302,7 +1303,7 @@ message CO2MeasureType {
1302
1303
1303
1304
// An address used to identify a contactable location.
1304
1305
messagePostalAddressType {
1305
-
// An optional identifier which can be used to reference the address elsewhere in the BOM. Every bom-ref MUST be unique within the BOM.
1306
+
// An optional identifier which can be used to reference the address elsewhere in the BOM. Every bom-ref must be unique within the BOM.
1306
1307
optionalstringbom_ref=1;
1307
1308
// The country name or the two-letter ISO 3166-1 country code.
Copy file name to clipboardExpand all lines: schema/bom-1.6.schema.json
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1161,7 +1161,7 @@
1161
1161
"contentType": {
1162
1162
"type": "string",
1163
1163
"title": "Content-Type",
1164
-
"description": "Specifies the format and nature of the data being attached, helping systems correctly interpret and process the content. Common content type examples include `application/json` for JSON data and `text/plain` for plan text documents. [RFC 2045 section 5.1](https://www.ietf.org/rfc/rfc2045.html#section-5.1) outlines the structure and use of content types. For a comprehensive list of registered content types, refer to the [IANA media types registry](https://www.iana.org/assignments/media-types/media-types.xhtml).",
1164
+
"description": "Specifies the format and nature of the data being attached, helping systems correctly interpret and process the content. Common content type examples include `application/json` for JSON data and `text/plain` for plan text documents.\n [RFC 2045 section 5.1](https://www.ietf.org/rfc/rfc2045.html#section-5.1) outlines the structure and use of content types. For a comprehensive list of registered content types, refer to the [IANA media types registry](https://www.iana.org/assignments/media-types/media-types.xhtml).",
0 commit comments