Converting links from spdx -> spdx2.2

software/example1/README.md

@@ -14,7 +14,7 @@ content
 One [C source file](content/src/hello.c) with a simple "hello world" program, compiled into a [single binary](content/build/hello) with no dependencies via a [Makefile](content/src/Makefile).
 (Assumed dependencies such as the operating system kernel, C standard library, etc. are not addressed here.)
 
-One [SPDX document](spdx/example1.spdx) showing the Makefile, source file and binary, together as a single package.
+One [SPDX document](spdx2.2/example1.spdx) showing the Makefile, source file and binary, together as a single package.
 
 This assumes of course that all three files are in fact being distributed together as a single package.
 

software/example2/README.md

@@ -13,13 +13,13 @@ content
 
 The content is identical to [example1](../example1): one [C source file](content/src/hello.c) with a simple "hello world" program, compiled into a [single binary](content/build/hello) with no dependencies via a [Makefile](content/src/Makefile).
 
-However, where example1 had a single SPDX document containing both source and binary, example2 instead has separate SPDX documents for [source](spdx/example2-src.spdx) and [binary](spdx/example2-bin.spdx).
+However, where example1 had a single SPDX document containing both source and binary, example2 instead has separate SPDX documents for [source](spdx2.2/example2-src.spdx) and [binary](spdx2.2/example2-bin.spdx).
 
 This describes a scenario where binary and source are distributed separately, but where we want to be able to reflect the relationships between binary and source packages.
 
 ## Comments
 
-Substantively, this is the same software as in [example1](../example).
+Substantively, this is the same software as in [example1](../example1).
 However, here we are representing the sources and binaries as two separate Packages, on the assumption that we're distributing them separately.
 Because of this, the source Package and binary Package are described in two separate SPDX documents.
 
@@ -31,6 +31,6 @@ Relationships across separate documents are handled via `DocumentRef-` tags, def
 Note that these external document references and relationships cannot be circular: one document can refer to the other, but (to my knowledge) they cannot refer circularly to each other.
 To reference another document in an ExternalDocumentRef definition, you need to specify its hash, so it isn't possible for two documents to refer to one another; each would need to modify its own contents based on the other's hash value.
 
-In the [SPDX document for the binary](spdx/example2-bin.spdx), note how the Relationships at the end of the document include `DocumentRef-hello-src:` as a prefix.
+In the [SPDX document for the binary](spdx2.2/example2-bin.spdx), note how the Relationships at the end of the document include `DocumentRef-hello-src:` as a prefix.
 This uses the `DocumentRef-` defined in the `ExternalDocumentRef` tag at the top of the document.
 This is the mechanism used to refer to SPDX identifiers for elements defined in other SPDX documents.

software/example3/README.md

@@ -19,13 +19,13 @@ This file carries a BSD-3-Clause license.
 The other [contains a main function](content/src/main.c) which dynamically loads and uses the function from the library file.
 This file carries a GPL-3.0-or-later license.
 
-As with example2, there are separate SPDX documents for [source](spdx/example3-src.spdx) and [binary](spdx/example3-bin.spdx).
+As with example2, there are separate SPDX documents for [source](spdx2.2/example3-src.spdx) and [binary](spdx2.2/example3-bin.spdx).
 
 This describes a scenario where there are multiple binary files, and we want to represent the dependency and dynamic-linking relationship between the binary files.
 
 ## Comments
 
-Note that the [binary SPDX document](spdx/example3-bin.spdx) includes the `RUNTIME_DEPENDENCY_OF` relationship between the main binary and the library binary.
+Note that the [binary SPDX document](spdx2.2/example3-bin.spdx) includes the `RUNTIME_DEPENDENCY_OF` relationship between the main binary and the library binary.
 There are many different dependency types of Relationships defined in [v2.2 of the SPDX spec](https://spdx.github.io/spdx-spec/7-relationships-between-SPDX-elements/).
 We could have also used, e.g., `DEPENDENCY_OF` and/or `PREREQUISITE_FOR`.
 `RUNTIME_DEPENDENCY_OF` was chosen here because of the extra specificity that the library is 'required for the execution' of the main binary.

software/example4/README.md

@@ -29,7 +29,7 @@ According to `readelf`, the example4 binary `main` relies on two shared librarie
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 ```
 
-In [`example4-bin.spdx`](spdx/example4-bin.spdx), we can create Package Information sections for each of `libdl` and `libc`.
+In [`example4-bin.spdx`](spdx2.2/example4-bin.spdx), we can create Package Information sections for each of `libdl` and `libc`.
 Keep in mind that these are _not_ files that are provided by the software distribution that the SPDX documents reflect: the `content/` directory does not contain libdl.so.2 or libc.so.6.
 Because they are not part of the software distribution that the SPDX document is primarily describing, there is _not_ a `DESCRIBES` relationship between the document and these shared libraries.
 

software/example6/README.md

@@ -15,9 +15,9 @@ The content is identical to [example5](../example5).
 Nothing has changed -- in fact, the comments still refer to "Example 5" -- for illustration purposes, so that the file hashes are identical to those in Example 5.
 
 The differences are in the SPDX documents.
-The [sources SPDX document](spdx/example6-src.spdx) is substantively identical to its Example 5 counterpart.
-However, we've introduced [a new (third) SPDX document](spdx/example6-lib.spdx), this one describing the Go distribution used to build the Hello World program, along with Packages describing a small portion of its contents.
-The [binary SPDX document](spdx/example6-bin.spdx) then includes Relationships describing how some portions of the Go distribution relate to the build results -- e.g., referencing the compiler used to build it, and the standard libraries that are incorporated into / statically linked with the binary.
+The [sources SPDX document](spdx2.2/example6-src.spdx) is substantively identical to its Example 5 counterpart.
+However, we've introduced [a new (third) SPDX document](spdx2.2/example6-lib.spdx), this one describing the Go distribution used to build the Hello World program, along with Packages describing a small portion of its contents.
+The [binary SPDX document](spdx2.2/example6-bin.spdx) then includes Relationships describing how some portions of the Go distribution relate to the build results -- e.g., referencing the compiler used to build it, and the standard libraries that are incorporated into / statically linked with the binary.
 
 ## Comments