Merge branch 'development/v3.0.1' into update-chap-intro

bact · Aug 9, 2024 · 86e2df3 · 86e2df3
2 parents cf1967b + 529433c
commit 86e2df3
Show file tree

Hide file tree

Showing 2 changed files with 65 additions and 39 deletions.
diff --git a/docs/annexes/diffs-from-previous-editions.md b/docs/annexes/diffs-from-previous-editions.md
@@ -209,54 +209,55 @@ The completeness property would be constructed based on the following:
 - “to” value is NOASSERTION: noAssertion
 - “to” value is an SPDX element: No value for the completeness - uses the default
 
-Relationship migration is being worked out in the relationships spreadsheet.  Once completed, the following table will reflect the translation for relationship types from SPDX 2.3 to SPDX 3.0:
+The following table reflects the translation for relationship types from SPDX 2.3 to SPDX 3.0:
 
 | SPDX 2.3 Relationship Type | SPDX 3.0 Relationship Type | Swap to and from? | LifecycleScopeType |
 |----------------------------|----------------------------|-------------------|--------------------|
 | AMENDS | amendedBy | Y | |
 | ANCESTOR_OF | ancestorOf | | |
-| BUILD_DEPENDENCY_OF | dependsOn | | build |
-| BUILD_TOOL_OF | usesTool | | build (all lifecycle scope could be appropriate) |
+| BUILD_DEPENDENCY_OF | dependsOn | Y | build |
+| BUILD_TOOL_OF | usesTool | Y | build |
 | CONTAINED_BY | contains | Y | |
 | CONTAINS | contains | | |
-| COPY_OF | copiedTo | | |
-| DATA_FILE_OF | hasDataFile | | |
-| DEPENDENCY_MANIFEST_OF | hasDependencyManifest | | |
-| ~~DEPENDENCY_OF~~ | [removed] | | |
-| DEPENDS_ON | dependsOn | | various LifecycleScopeType |
-| DESCENDANT_OF | decendentOf | | |
-| ~~DESCRIBED_BY~~ | [removed] | | |
+| COPY_OF | copiedTo | Y | |
+| DATA_FILE_OF | hasDataFile | Y | |
+| DEPENDENCY_MANIFEST_OF | hasDependencyManifest | Y | |
+| DEPENDENCY_OF | dependsOn | Y | various lifecycle scope |
+| DEPENDS_ON | dependsOn | | various lifecycle scope |
+| DESCENDANT_OF | descendantOf | | |
+| DESCRIBED_BY | describes | Y | |
 | DESCRIBES | describes | | |
-| DEV_DEPENDENCY_OF | dependsOn | | development |
-| DEV_TOOL_OF | usesTool | | development |
+| DEV_DEPENDENCY_OF | dependsOn | Y | development |
+| DEV_TOOL_OF | usesTool | Y | development |
 | DISTRIBUTION_ARTIFACT | hasDistributionArtifact | | |
-| DOCUMENTATION_OF | hasDocumentation | | |
-| DYNAMIC_LINK | hasDynamicLink | | build, runtime |
-| EXAMPLE_OF | hasExample | | |
-| EXPANDED_FROM_ARCHIVE | expandsTo | | |
-| FILE_ADDED | hasAddedFile | | |
-| FILE_DELETED | hasDeletedFile | | |
+| DOCUMENTATION_OF | hasDocumentation | Y | |
+| DYNAMIC_LINK | hasDynamicLink | Y | build, runtime |
+| EXAMPLE_OF | hasExample | Y | |
+| EXPANDED_FROM_ARCHIVE | expandsTo | Y | |
+| FILE_ADDED | hasAddedFile | Y | |
+| FILE_DELETED | hasDeletedFile | Y | |
 | FILE_MODIFIED | modifiedBy | | |
 | GENERATED_FROM | generates | Y | |
 | GENERATES | generates | | |
-| HAS_PREREQUISITE | hasPrequisite | | lifecycle scope |
-| METAFILE_OF | hasMetadata | | |
-| OPTIONAL_COMPONENT_OF | hasOptionalComponent | | |
-| OPTIONAL_DEPENDENCY_OF | hasOptionalDependency | | lifecycle scope |
+| HAS_PREREQUISITE | hasPrerequisite | | various lifecycle scope |
+| METAFILE_OF | hasMetadata | Y | |
+| OPTIONAL_COMPONENT_OF | hasOptionalComponent | Y | |
+| OPTIONAL_DEPENDENCY_OF | hasOptionalDependency | Y | various lifecycle scope |
 | OTHER | other | | |
-| PACKAGE_OF | packagedBy | | |
-| ~~PATCH_FOR~~ | [removed] | | |
-| ~~PREREQUISITE_FOR~~ | [removed] | | |
-| PROVIDED_DEPENDENCY_OF | hasProvidedDependency | | lifecycle scope |
-| REQUIREMENT_DESCRIPTION_FOR | hasRequirement | | lifecycle scope |
-| RUNTIME_DEPENDENCY_OF | dependsOn | | runtime |
-| SPECIFICATION_FOR | hasSpecification | | lifecycle scope |
-| STATIC_LINK | hasStaticLink | | lifecycle scope |
-| TEST_CASE_OF | hasTestCase | | |
-| TEST_DEPENDENCY_OF | dependsOn | | test |
-| TEST_OF | hasTest | | lifecycle scope |
-| TEST_TOOL_OF | usesTool | | test |
-| VARIANT_OF | hasVarient | | |
+| PACKAGE_OF | packagedBy | Y | |
+| PATCH_FOR | patchedBy | Y | |
+| PATCH_APPLIED | patchedBy | Y | |
+| PREREQUISITE_FOR | hasPrerequisite | Y | various lifecycle scope |
+| PROVIDED_DEPENDENCY_OF | hasProvidedDependency | Y | various lifecycle scope |
+| REQUIREMENT_DESCRIPTION_FOR | hasRequirement | Y | various lifecycle scope |
+| RUNTIME_DEPENDENCY_OF | dependsOn | Y | runtime |
+| SPECIFICATION_FOR | hasSpecification | Y | various lifecycle scope |
+| STATIC_LINK | hasStaticLink | | various lifecycle scope |
+| TEST_CASE_OF | hasTestCase | Y | |
+| TEST_DEPENDENCY_OF | dependsOn | Y | test |
+| TEST_OF | hasTest | Y | various lifecycle scope |
+| TEST_TOOL_OF | usesTool | Y | test |
+| VARIANT_OF | hasVariant | Y | |
 
 ##### Rationale
 

diff --git a/docs/serializations.md b/docs/serializations.md
@@ -1,22 +1,23 @@
 # 4 Model and serializations
 
-## 4.1 Overview
+## 4.1 Overview <a name="4.1"></a>
 
 This specification defines the data model of the SPDX standard, describing every piece of information about systems with software components. The data model is based on the Resource Description Framework (RDF) extensible knowledge representation data model, which provides a flexible and extensible way to represent and exchange information.
 
 The data may be serialized in a variety of formats for storage and transmission.
 
-## 4.2 RDF Serialization
+## 4.2 RDF Serialization <a name="4.2"></a>
 
 Since the data model is based on RDF, any SPDX data can be serialized in any of the multiple RDF serialization formats, including but not limited to:
+
 - JSON-LD format as defined in [JSON-LD 1.1](https://www.w3.org/TR/json-ld11/);
 - Turtle (Terse RDF Triple Language) format as defined in [RDF 1.1 Turtle](https://www.w3.org/TR/turtle/);
 - N-Triples format as defined in [RDF 1.1 N-Triples](https://www.w3.org/TR/n-triples/); and
 - RDF/XML format as defined in [RDF 1.1 XML Syntax](https://www.w3.org/TR/rdf-syntax-grammar/).
 
 The SPDX specification is accompanied by a [JSON-LD context](https://www.w3.org/TR/json-ld11/#the-context) definition file that can be used to serialize SPDX in a much simpler and more human-readable JSON-LD format.
 
-## 4.3 Canonical serialization
+## 4.3 Canonical serialization <a name="4.3"></a>
 
 Canonical serialization is single, consistent, normalized, deterministic, and reproducible form.
 
@@ -33,4 +34,28 @@ Canonical serialization is in JSON format, as defined in RFC 8259 (IETF STD 90),
 - integers: represented in base 10 using decimal digits. This designates an integer component that may be prefixed with an optional minus sign. Leading zeros are not allowed.
 - strings: UTF-8 representation without specific canonicalisation. A string begins and ends with quotation marks (%x22). Any Unicode characters may be placed within the quotation marks, except for the two characters that MUST be escaped by a reverse solidus: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F).
 - arrays: An array structure is represented as square brackets surrounding zero or more items. Items are separated by commas.
-- objects: An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string containing only ASCII characters (0x21-0x7F). The names within an object must be unique. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The name/value pairs are ordered by name.
+- objects: An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string containing only ASCII characters (0x21-0x7F). The names within an object must be unique. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The name/value pairs are ordered by name.
+
+## 4.4 Serialization information <a name="4.4"></a>
+
+A collection of elements may be serialized in multiple formats.
+
+An SpdxDocument element represents a collection of
+elements across all serialization data formats within the model.
+
+The actual serialized bytes is represented by an Artifact element within the
+model.
+
+A Relationship of type serializedInArtifact links an SpdxDocument to one or
+more serialized forms of itself.
+
+When serializing a physical SpdxDocument, any property of the logical element
+that can be natively represented within the chosen serialization format
+(e.g., @context prefixes in JSON-LD instead of the namespaceMap) may utilize
+these native mechanisms. All remaining properties shall be serialized within
+the SpdxDocument element itself.
+
+A serialization must not contain more than one SpdxDocument.
+
+A given instance of serialization must not define more than one SpdxDocument
+element.