Merge pull request #612 from package-url/593-set-character-lines-to-78

Update /docs .md files to 78-column width max #593
Also change "MUST" to "must" and similar for Ecma standard terminology
Formatting changes only

Author: mjherzog

docs/how-to-build.md

@@ -11,7 +11,8 @@ To build a `purl` string from its components:
 
 - Start a `purl` string with the "pkg:" `scheme` as a lowercase ASCII string
 
-- Append the `type` string to the `purl` as an unencoded lowercase ASCII string
+- Append the `type` string to the `purl` as an unencoded lowercase ASCII
+  string
 
   - Append '/' to the `purl`
 

docs/known-qualifiers.md

@@ -2,34 +2,35 @@
 
 Note: Do not abuse `qualifiers`: it can be tempting to use many qualifier
 keys but their usage should be limited to the bare minimum for proper package
-identification to ensure that a `purl` stays compact and readable in most cases.
+identification to ensure that a `purl` stays compact and readable in most
+cases.
 
 Additional, separate external attributes stored outside of a `purl` are the
 preferred mechanism to convey extra long and optional information such as a
 download URL, VCS URL or checksums in an API, database or web form.
 
-With this warning, the known `key` and `value` defined here are valid for use in
-all package types:
+With this warning, the known `key` and `value` defined here are valid for use
+in all package types:
 
 - `vers` allows the specification of a version range.
-  The value MUST adhere to the `Version Range Specification`.
+  The value must adhere to the `Version Range Specification`.
   This qualifier is mutually exclusive with the `version` component.
   For example:
 
     pkg:pypi/django?vers=vers:pypi%2F%3E%3D1.11.0%7C%21%3D1.11.1%7C%3C2.0.0
 
 - `repository_url` is an extra URL for an alternative, non-default package
-  repository or registry. When a package does not come from the default public
-  package repository for its `type` a `purl` may be qualified with this extra
-  URL. The default repository or registry of a `type` is documented in the
-  "Registered `purl` types" section.
+  repository or registry. When a package does not come from the default
+  public package repository for its `type` a `purl` may be qualified with
+  this extra URL. The default repository or registry of a `type` is
+  documented in the "Registered `purl` types" section.
 
 - `download_url` is an extra URL for a direct package web download URL to
   optionally qualify a `purl`.
 
 - `vcs_url` is an extra URL for a package version control system URL to
-  optionally qualify a `purl`. The syntax for this URL should be as defined in
-  Python pip or the SPDX specification. See
+  optionally qualify a `purl`. The syntax for this URL should be as defined
+  in Python pip or the SPDX specification. See
   https://github.com/spdx/spdx-spec/blob/cfa1b9d08903/chapters/3-package-information.md#37-package-download-location
 
 - `file_name` is an extra file name of a package archive.

docs/purl-spec-toc.md

@@ -7,13 +7,12 @@ A `purl` or package URL is an attempt to standardize existing approaches to
 reliably identify and locate software packages.
 
 A `purl` is a URL string used to identify and locate a software package in a
-mostly universal and uniform way across programming languages, package managers,
-packaging conventions, tools, APIs and databases.
+mostly universal and uniform way across programming languages, package
+managers, packaging conventions, tools, APIs and databases.
 
 A `purl` is useful to reliably reference the same software package
 using a simple and expressive syntax and conventions based on familiar URLs.
 
-
 The Package-URL specification is organized in these documents:
 
 - What is `purl` aka. package URL? -- https://github.com/package-url/purl-spec/blob/docs/standard/summary.md

docs/standard/about.md

@@ -1,16 +1,22 @@
 # About this Specification
 
-The document at [https://tc54.org/ecmaXXX/](https://tc54.org/ecmaXXX/) is the most accurate and up-to-date Package-URL specification.
+The document at [https://tc54.org/ecmaXXX/](https://tc54.org/ecmaXXX/) is the
+most accurate and up-to-date Package-URL specification.
 
-This document is available as [a single page](https://ecma-tc54.github.io/ECMA-xxx-PURL/) and as [multiple pages](https://ecma-tc54.github.io/ECMA-xxx-PURL/multipage/).
+This document is available as [a single page](https://ecma-tc54.github.io/ECMA-xxx-PURL/)
+and as [multiple pages](https://ecma-tc54.github.io/ECMA-xxx-PURL/multipage/).
 
 # Contributing to this Specification
 
-This specification is developed on GitHub with the help of the Package-URL community. There are a number of ways to contribute to the development of this specification:
+This specification is developed on GitHub with the help of the Package-URL
+community. There are a number of ways to contribute to the development of
+this specification:
 
 * GitHub Repository: [https://github.com/Ecma-TC54/ECMA-xxx-PURL](https://github.com/Ecma-TC54/ECMA-xxx-PURL)
-* Issues: [All Issues](https://github.com/Ecma-TC54/ECMA-xxx-PURL/issues), [File a New Issue](https://github.com/Ecma-TC54/ECMA-xxx-PURL/issues/new)
-* Pull Requests: [All Pull Requests](https://github.com/Ecma-TC54/ECMA-xxx-PURL/pulls), [Create a New Pull Request](https://github.com/Ecma-TC54/ECMA-xxx-PURL/pulls/new)
+* Issues: [All Issues](https://github.com/Ecma-TC54/ECMA-xxx-PURL/issues),
+  [File a New Issue](https://github.com/Ecma-TC54/ECMA-xxx-PURL/issues/new)
+* Pull Requests: [All Pull Requests](https://github.com/Ecma-TC54/ECMA-xxx-PURL/pulls),
+  [Create a New Pull Request](https://github.com/Ecma-TC54/ECMA-xxx-PURL/pulls/new)
 * Editors:
   * [John Horan](mailto:jmhoran@aboutcode.org)
   * [Michael Herzog](mailto:mjherzog@aboutcode.org)
@@ -19,5 +25,5 @@ This specification is developed on GitHub with the help of the Package-URL commu
 * Community:
   * Chat: [Slack Channel](https://cyclonedx.slack.com/archives/C06KTE3BWEB)
 
-Refer to the [colophon](https://ecma-tc54.github.io/ECMA-xxx-PURL/#sec-colophon) for more information on how this document was created.
-
+Refer to the [colophon](https://ecma-tc54.github.io/ECMA-xxx-PURL/#sec-colophon)
+for more information on how this document was created.

docs/standard/components.md

@@ -4,7 +4,8 @@ A PURL string is an ASCII URL string composed of seven components.
 
 Except as expressly stated otherwise in this section, each component:
 
-- May be composed of any of the characters defined in the "Permitted characters" section
+- May be composed of any of the characters defined in the "Permitted
+  characters" section
 - Must be encoded as defined in the "Character encoding" section
 
 The "lowercase" rules are defined in the "Case folding" section.
@@ -31,7 +32,8 @@ The rules for each component are:
 
 - **namespace**:
 
-  - The `namespace` is optional, unless required by the package's `type` definition.
+  - The `namespace` is optional, unless required by the package's `type`
+    definition.
   - If present, the `namespace` may contain one or more segments, separated
     by a single unencoded slash '/' character.
   - All leading and trailing slashes '/' are not significant and should be
@@ -65,8 +67,8 @@ The rules for each component are:
   - The `version` is prefixed by a '@' separator when not empty.
   - This '@' is not part of the `version`.
   - A `version` must be a percent-encoded string.
-  - When percent-decoded, a `version` may contain any Unicode character unless
-    the package's `type` definition provides otherwise.
+  - When percent-decoded, a `version` may contain any Unicode character
+    unless the package's `type` definition provides otherwise.
   - A `version` is a plain and opaque string.
 
 
@@ -101,8 +103,8 @@ The rules for each component are:
   - The `subpath` string is prefixed by a '#' separator when not empty
   - The '#' is not part of the `subpath`
   - The `subpath` contains zero or more segments, separated by slash '/'
-  - Leading and trailing slashes '/' are not significant and should be stripped
-    in the canonical form
+  - Leading and trailing slashes '/' are not significant and should be
+    stripped in the canonical form
   - Each `subpath` segment must be a percent-encoded string
   - When percent-decoded, a segment:
 

docs/standard/conformance.md

@@ -2,33 +2,73 @@
 
 ## 2.1 Requirements Terminology
 
-In this standard, the words that are used to define the significance of each requirement are detailed below. These words are used in accordance with their definitions in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt), and their respective meanings are reproduced below:
-
-* Must: This word, or the adjective “required” and the auxiliary verb "shall", means that the item is an absolute requirement of the standard.
-* Should: This word, or the adjective “recommended”, means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before making an implementation decision.
-* May: This word, or the adjective “optional”, means that this item is truly optional.
-
-The words "must not", "shall not", "should not", and "not recommended", are the negative forms of "must", "shall", "should", and "recommended", respectively. There is no negative form of "may".
+In this standard, the words that are used to define the significance of each
+requirement are detailed below. These words are used in accordance with their
+definitions in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt), and their
+respective meanings are reproduced below:
+
+* Must: This word, or the adjective “required” and the auxiliary verb
+  "shall", means that the item is an absolute requirement of the standard.
+* Should: This word, or the adjective “recommended”, means that there might
+  exist valid reasons in particular circumstances to ignore this item, but
+  the full implications should be understood and the case carefully weighed
+  before making an implementation decision.
+* May: This word, or the adjective “optional”, means that this item is truly
+  optional.
+
+The words "must not", "shall not", "should not", and "not recommended", are
+the negative forms of "must", "shall", "should", and "recommended",
+respectively. There is no negative form of "may".
 
 ## 2.2 Implementation Conformance
 
-A conforming implementation of Package-URL (PURL) must fully implement and support all elements defined within this specification, including the syntax, components, and semantic requirements for constructing and interpreting valid PURLs.
-
-A conforming implementation of PURL must adhere to the syntax defined in this specification, ensuring that all PURLs are parsed, constructed, and validated according to the prescribed rules. The implementation must provide full support for ecosystem-agnostic behaviour, enabling PURLs to function consistently and reliably across diverse environments.
-
-All required components of a PURL, such as the scheme, type, and name, must be present and validated according to the rules defined in this specification. Additionally, optional components, including qualifiers and subpaths, must be handled appropriately if provided, in full compliance with their specified behaviours.
-
-Implementations must ensure that equivalent PURLs are consistently resolved to the same canonical representation. This includes strict adherence to normalisation and equivalence rules. Furthermore, implementations must process URI encoding and decoding for PURL components according to the standards outlined in RFC 3986.
-
-Invalid PURLs that fail to conform to the specification must be identified and rejected by any conforming implementation. This guarantees the integrity and reliability of PURLs in all supported contexts.
-
-A conforming implementation of PURL may extend its functionality by providing ecosystem-specific validation, processing, or metadata handling, as long as these extensions do not violate the core specification. Additionally, implementations may offer auxiliary tools or features, such as utilities for constructing or validating PURLs, provided they align with the standard's requirements.
-
-A conforming implementation must not redefine or alter the core syntax, components, or semantics defined by this specification. Any prohibited extensions explicitly identified in the specification must not be implemented. Furthermore, behaviours that compromise the interoperability of PURLs across tools, platforms, or ecosystems are strictly disallowed.
-
-A conforming implementation of Package-URL may choose to implement or not implement Normative Optional subclauses. If any Normative Optional behaviour is implemented, all of the behaviour in the containing Normative Optional clause must be implemented. A Normative Optional clause is denoted in this specification with the words "Normative Optional" in a coloured box, as shown below.
+A conforming implementation of Package-URL (PURL) must fully implement and
+support all elements defined within this specification, including the syntax,
+components, and semantic requirements for constructing and interpreting valid
+PURLs.
+
+A conforming implementation of PURL must adhere to the syntax defined in this
+specification, ensuring that all PURLs are parsed, constructed, and validated
+according to the prescribed rules. The implementation must provide full
+support for ecosystem-agnostic behaviour, enabling PURLs to function
+consistently and reliably across diverse environments.
+
+All required components of a PURL, such as the scheme, type, and name, must
+be present and validated according to the rules defined in this
+specification. Additionally, optional components, including qualifiers and
+subpaths, must be handled appropriately if provided, in full compliance with
+their specified behaviours.
+
+Implementations must ensure that equivalent PURLs are consistently resolved
+to the same canonical representation. This includes strict adherence to
+normalisation and equivalence rules. Furthermore, implementations must
+process URI encoding and decoding for PURL components according to the
+standards outlined in RFC 3986.
+
+Invalid PURLs that fail to conform to the specification must be identified
+and rejected by any conforming implementation. This guarantees the integrity
+and reliability of PURLs in all supported contexts.
+
+A conforming implementation of PURL may extend its functionality by providing
+ecosystem-specific validation, processing, or metadata handling, as long as
+these extensions do not violate the core specification. Additionally,
+implementations may offer auxiliary tools or features, such as utilities for
+constructing or validating PURLs, provided they align with the standard's
+requirements.
+
+A conforming implementation must not redefine or alter the core syntax,
+components, or semantics defined by this specification. Any prohibited
+extensions explicitly identified in the specification must not be
+implemented. Furthermore, behaviours that compromise the interoperability of
+PURLs across tools, platforms, or ecosystems are strictly disallowed.
+
+A conforming implementation of Package-URL may choose to implement or not
+implement Normative Optional subclauses. If any Normative Optional behaviour
+is implemented, all of the behaviour in the containing Normative Optional
+clause must be implemented. A Normative Optional clause is denoted in this
+specification with the words "Normative Optional" in a coloured box, as shown
+below.
 
 ## 2.3 Example Normative Optional Clause Heading
 
 Example clause contents.
-