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.

Sign up for GitHub

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

Jump to bottom

RelationshipType: hasInputs/hasOutputs -> hasInput/hasOutput #854

Merged
merged 2 commits into from
Aug 14, 2024
Merged

RelationshipType: hasInputs/hasOutputs -> hasInput/hasOutput #854

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9bf9a41
hasInputs/hasOutputs -> hasInput/hasOutput
bact Aug 14, 2024
ebbad82
Update CHANGELOG.md
bact Aug 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Change Log

## 3.0.1 (under development - last update 2024-08-10)
## 3.0.1 (under development - last update 2024-08-14)

### Changes since 3.0

Expand All @@ -17,6 +17,9 @@
- Corrected `imports` to `import` in Core Profile.
- **Fixed:** Typo in `Build/parameter` property - [#836](https://github.com/spdx/spdx-3-model/pull/836)
- Corrected `parameters` to `parameter` in Build Profile.
- **Fixed:** Typo in `hasInput` and `hasOutput` relationship type names - [#854](https://github.com/spdx/spdx-3-model/pull/854)
- Corrected `hasInputs` to `hasInput` and `hasOutputs` to `hasOutput` in
`Core/RelationshipType`.
- **Added:** `adler32` entry to `Core/HashAlgorithm` - [#826](https://github.com/spdx/spdx-3-model/pull/826)
- The Adler-32 checksum, previously available in SPDX 2.3, has been
reintroduced.
Expand Down
10 changes: 5 additions & 5 deletions model/Build/Build.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,8 +20,8 @@ The Build profile provides a subclass of Element called Build.
It also provides a minimum set of required Relationship Types from the Core
profile:

- hasInputs: Describes the relationship from the Build element to its inputs.
- hasOutputs: Describes the relationship from the Build element to its outputs.
- hasInput: Describes the relationship from the Build element to its inputs.
- hasOutput: Describes the relationship from the Build element to its outputs.
- invokedBy: Describes the relationship from the Build element to the Agent
that invoked it.

Expand All @@ -40,7 +40,7 @@ In addition, the following Relationship Types may be used to describe a Build.
All relationships in the Build Profile are scoped to the "build"
LifecycleScopeType period.

The `hasInputs` relationship can be applied to a config file or a build tool if
The `hasInput` relationship can be applied to a config file or a build tool if
the nature of these inputs are not known at the creation of an SPDX document.

## Metadata
Expand All @@ -55,7 +55,7 @@ class. In addition, there must be at least three instances `Relationship`s with
type `LifecycleScopedRelationship`, where the "scope" property must be "build"
and the "from" property must be the Build instance.

At the minimum, the build profile must contain a `hasInputs`, `hasOutputs`, and
At the minimum, the build profile must contain a `hasInput`, `hasOutput`, and
`invokedBy` relationshipType. If an input is known to be a build configuration
or a build tool, the `hasInputs` relationshipType can be replaced by a
or a build tool, the `hasInput` relationshipType can be replaced by a
`configures` or `usesTool` relationshipType.
6 changes: 3 additions & 3 deletions model/Core/Vocabularies/RelationshipType.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ name completes the sentence:
- hasAssessmentFor: Relates a `from` Vulnerability and each `to` Element(s) with a security assessment. To be used with `VulnAssessmentRelationship` types.
- hasAssociatedVulnerability: Used to associate a `from` Artifact with each `to` Vulnerability.
- hasConcludedLicense: The `from` Software Artifact is concluded by the SPDX data creator to be governed by each `to` license.
- hasDataFile: The `from` Element treats each `to` Element as a data file. A data file is an artifact that stores data required or optional for the `from` Element's functionality. A data file can be a database file, an index file, a log file, an AI model file, a calibration data file, a temporary file, a backup file, and more. For AI training dataset, test dataset, test artifact, configuration data, build input data, and build output data, please consider using the more specific relationship types: `trainedOn`, `testedOn`, `hasTest`, `configures`, `hasInputs`, and `hasOutputs`, respectively. This relationship does not imply dependency.
- hasDataFile: The `from` Element treats each `to` Element as a data file. A data file is an artifact that stores data required or optional for the `from` Element's functionality. A data file can be a database file, an index file, a log file, an AI model file, a calibration data file, a temporary file, a backup file, and more. For AI training dataset, test dataset, test artifact, configuration data, build input data, and build output data, please consider using the more specific relationship types: `trainedOn`, `testedOn`, `hasTest`, `configures`, `hasInput`, and `hasOutput`, respectively. This relationship does not imply dependency.
- hasDeclaredLicense: The `from` Software Artifact was discovered to actually contain each `to` license, for example as detected by use of automated tooling.
- hasDeletedFile: Every `to` Element is a file deleted from the `from` Element (`from` hasDeletedFile `to`).
- hasDependencyManifest: The `from` Element has manifest files that contain dependency information in each `to` Element.
Expand All @@ -58,11 +58,11 @@ name completes the sentence:
- hasEvidence: Every `to` Element is considered as evidence for the `from` Element (`from` hasEvidence `to`).
- hasExample: Every `to` Element is an example for the `from` Element (`from` hasExample `to`).
- hasHost: The `from` Build was run on the `to` Element during a LifecycleScopeType period (e.g. the host that the build runs on).
- hasInputs: The `from` Build has each `to` Elements as an input, during a LifecycleScopeType period.
- hasInput: The `from` Build has each `to` Elements as an input, during a LifecycleScopeType period.
- hasMetadata: Every `to` Element is metadata about the `from` Element (`from` hasMetadata `to`).
- hasOptionalComponent: Every `to` Element is an optional component of the `from` Element (`from` hasOptionalComponent `to`).
- hasOptionalDependency: The `from` Element optionally depends on each `to` Element, during a LifecycleScopeType period.
- hasOutputs: The `from` Build element generates each `to` Element as an output, during a LifecycleScopeType period.
- hasOutput: The `from` Build element generates each `to` Element as an output, during a LifecycleScopeType period.
- hasPrerequisite: The `from` Element has a prerequisite on each `to` Element, during a LifecycleScopeType period.
- hasProvidedDependency: The `from` Element has a dependency on each `to` Element, dependency is not in the distributed artifact, but assumed to be provided, during a LifecycleScopeType period.
- hasRequirement: The `from` Element has a requirement on each `to` Element, during a LifecycleScopeType period.
Expand Down