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

CHANGELOG.md

@@ -1,11 +1,16 @@
 # Change Log
+
 All notable changes to this project will be documented in this file.
 
-## 3.0
+## 3.0 (2024-04-15)
+
+See the v3.0 GitHub release notes for changes
+[in the spec](https://github.com/spdx/spdx-spec/releases/tag/v3.0) and
+[in the model](https://github.com/spdx/spdx-3-model/releases/tag/3.0).
 
-See the [v3.0 GitHub release notes](https://github.com/spdx/spdx-spec/releases/tag/v3.0) for changes.
+See also the [SPDX specification 3.0 release announcement](https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases)
 
-## 2.3
+## 2.3 (2022-11-03)
 
 See the [v2.3 GitHub release notes](https://github.com/spdx/spdx-spec/releases/tag/v2.3) for changes.
 

CONTRIBUTING.md

@@ -1,44 +1,83 @@
 # Contributing
 
-The SPDX specification is maintained by the SPDX [legal][spdx-legal] and [tech][spdx-tech] teams.
-Design and planning is primarily done via the team [mailing][spdx-legal-list] [lists][spdx-tech-list] and meetings.
+The SPDX specification is maintained by the SPDX [legal][spdx-legal] and
+[tech][spdx-tech] teams.
+Design and planning is primarily done via the team [mailing][spdx-legal-list]
+[lists][spdx-tech-list] and [meetings][meetings].
 
 ## Contribution License Agreement
 
-Contributions to this repo are made pursuant to the [SPDX Community Specification Contributor License Agreement 1.0][cla]. You do not need to submit a signed copy of the contributor license agreement; by making a contribution to this repo, you agree to the terms set forth in that agreement.
+Contributions to this repo are made pursuant to the
+[SPDX Community Specification Contributor License Agreement 1.0][cla]. You do
+not need to submit a signed copy of the contributor license agreement; by
+making a contribution to this repo, you agree to the terms set forth in that
+agreement.
 
 ## Submitting changes
 
-Always write a clear log message for your commits. One-line messages are fine for small changes, but significant changes should look like this:
+Always write a clear log message for your commits. One-line messages are fine
+for small changes, but significant changes should look like this:
 
-    $ git commit -m "Subject of the commit
-    > 
-    > A paragraph describing what changed and its impact."
+```shell
+$ git commit -m "Subject of the commit
+>
+> A paragraph describing what changed and its impact.
+>
+> Signed-off-by: Contributor Name <name@example.com>"
+```
 
-A properly formed Git commit subject line should always be able to complete the following sentence: if applied, this commit will "Subject of the commit". For example :
+Every commit message also needs a sign-off line, or it will not pass a test in
+the workflow. This line starts with `Signed-off-by:` and specifies the name and
+the email address of the person who submitted the changes. You can also use the
+`-s` or `--signoff` option with `git commit` to automatically append the line
+to your commit message (it will use `user.name` and `user.email` from your
+`.git/config` configuration file).
 
-    if applied, this commit will Add chapter on Security Vunerabilities in SPDX
-    if applied, this commit will Delete section with deprecated SPDX attributes 
-    if applied, this commit will Fix grammar in Package Version field description
+A properly formed Git commit subject line should always be able to complete the
+following sentence: if applied, this commit will "Subject of the commit".
 
-Git itself uses this approach. When you merge something it will generate a commit message like "Merge branch...", or when reverting "Revert...".
+For example :
+
+```text
+if applied, this commit will Add chapter on Security Vunerabilities in SPDX
+if applied, this commit will Delete section with deprecated SPDX attributes 
+if applied, this commit will Fix grammar in Package Version field description
+```
+
+Git itself uses this approach. When you merge something it will generate a
+commit message like "Merge branch...", or when reverting "Revert...".
 
 ### Minor Changes
-Minor changes such as markup and typo fixes may be submitted directly to this repository (either as [issues][] or [pull-requests][]) without previous discussion.
-Please submit all minor changes against the `development/v2.3` branch which is the current version of the SPDX specification.
+
+Minor changes such as markup and typo fixes may be submitted directly to this
+repository (either as [issues][] or [pull-requests][]) without previous
+discussion.
+
+Please submit all minor changes against the `development/v3.0.1` branch which
+is the current development version of the SPDX specification.
 
 ### Major Changes
-Any change that break backwards compatibility or requires significant tooling changes is considered a major change.
-You may want to discuss major changes on the mailing list first to get design feedback before investing time in a pull request.
-Please submit all major changes against the `development/v3.0` which is the next major version of the specification. 
+
+Any change that break backwards compatibility or requires significant tooling
+changes is considered a major change.
+You may want to discuss major changes on the mailing list first to get design
+feedback before investing time in a pull request.
+
+Please submit all major changes against the `development/v3.1` which is the
+next major version of the specification.
 
 ### Target Milestones
-When submitting an issue or pull request, please add a suggested release milestone.  This will ensure the issue or pull request is reviewed for inclusion in that release.
 
-If your issue or pull request is independent of a release, you can use the `release-independent` milestone.
+When submitting an issue or pull request, please add a suggested release
+milestone. This will ensure the issue or pull request is reviewed for inclusion
+in that release.
+
+If your issue or pull request is independent of a release, you can use the
+`release-independent` milestone.
 
 [cla]: https://github.com/spdx/governance/blob/main/0._SPDX_Contributor_License_Agreement.md
 [issues]: https://github.com/spdx/spdx-spec/issues/
+[meetings]: https://github.com/spdx/meetings/
 [pull-requests]: https://github.com/spdx/spdx-spec/pulls/
 [spdx-legal]: https://wiki.spdx.org/view/Legal_Team
 [spdx-legal-list]: https://lists.spdx.org/mailman/listinfo/spdx-legal

docs/serializations.md

@@ -2,39 +2,69 @@
 
 ## 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 <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.
+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 <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 <a name="4.3"></a>
 
-Canonical serialization is single, consistent, normalized, deterministic, and reproducible form.
+Canonical serialization is a single, consistent, normalized, deterministic, and
+reproducible form.
 
 Such a canonical form normalizes things like ordering and formatting.
 
-The content of the canonical serialization is exactly the same as the JSON-LD serialization of RDF data (see 4.2), just represented in a consistent way.
-
-Canonical serialization is in JSON format, as defined in RFC 8259 (IETF STD 90), with the following additional characteristics:
-
-- no line breaks
-- key names MUST be wrapped in double quotes
-- no whitespace outside of strings
-- true, false and null: the literal names must be lowercase; no other literal names are allowed
-- 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.
+The content of the canonical serialization is exactly the same as the JSON-LD
+serialization of RDF data (see 4.2), just represented in a consistent way.
+
+Canonical serialization is in JSON format, as defined in
+[RFC 8259 (IETF STD 90)](https://www.rfc-editor.org/info/rfc8259),
+with the following additional characteristics:
+
+- No line breaks
+- Key names MUST be wrapped in double quotes
+- No whitespace outside of strings
+- `true`, `false` and `null`: the literal names must be lowercase; no other
+  literal names are allowed
+- 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.
 
 ## 4.4 Serialization information <a name="4.4"></a>
 
@@ -51,7 +81,7 @@ 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
+(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.