fix: various markdown fixes and streamlinings

.editorconfig

@@ -0,0 +1,4 @@
+
+[*.md]
+trim_trailing_whitespace = false
+

Attestations/en/0x60-Signing.md

@@ -11,13 +11,13 @@ CycloneDX supports signing to ensure the authenticity and integrity of the attes
 The personas that could sign claims, evidence, standards, or attestations can be categorized into two main groups:
 
 * `Producers`: These are the entities responsible for creating and managing the SBOMs and attestations. They could include:
-    * `Software developers`: Developers of software components or applications are often responsible for generating claims that accurately reflect their Software Development Lifecycle (SDL).
-    * `Software distributors`: Distributors of software packages may create SBOMs that aggregate the SBOMs of individual components included in their packages and provide assurances for the software packages in the form of assurances.
-    * `Build or deployment tools`: Automated build or deployment tools can generate SBOMs and evidence for supporting the claims required by the developers as part of their workflow, ensuring that the SBOMs are up-to-date with the latest code changes and the claims are supported .
-    * `Software supply chain security tools`: Security tools can analyze SBOMs to identify potential vulnerabilities, compliance issues, or other relevant information and generate evidence of security testing and validation.
+  * `Software developers`: Developers of software components or applications are often responsible for generating claims that accurately reflect their Software Development Lifecycle (SDL).
+  * `Software distributors`: Distributors of software packages may create SBOMs that aggregate the SBOMs of individual components included in their packages and provide assurances for the software packages in the form of assurances.
+  * `Build or deployment tools`: Automated build or deployment tools can generate SBOMs and evidence for supporting the claims required by the developers as part of their workflow, ensuring that the SBOMs are up-to-date with the latest code changes and the claims are supported .
+  * `Software supply chain security tools`: Security tools can analyze SBOMs to identify potential vulnerabilities, compliance issues, or other relevant information and generate evidence of security testing and validation.
 * `Verifiers`: These are the entities responsible for validating and verifying the authenticity and integrity of SBOMs or attestations. They could include:
-    * `Organizations consuming software`: Organizations that use or integrate software components may require attestations that meet a certain standard. (e.g: PCI-DSS certified software)
-    * `Regulatory bodies or auditors`: Regulatory bodies or auditors may use the claims, evidence and attestation generated by the software producers as part of compliance audits or certification processes.
+  * `Organizations consuming software`: Organizations that use or integrate software components may require attestations that meet a certain standard. (e.g: PCI-DSS certified software)
+  * `Regulatory bodies or auditors`: Regulatory bodies or auditors may use the claims, evidence and attestation generated by the software producers as part of compliance audits or certification processes.
 
 In some cases, a single entity may act as both a producer and a verifier of SBOMs or attestations. For example, a software development company may generate SBOMs and attestations for its own products and also verify them from its suppliers.
 

CBOM/en/0x60-Linking.md

@@ -5,22 +5,27 @@ systems or other BOMs. This deep-linking capability is referred to as BOM-Link a
 and compliant with [RFC-8141](https://www.rfc-editor.org/rfc/rfc8141.html). 
 
 **Syntax**:
-```ini
-urn:cdx:serialNumber/version#bom-ref
+```text
+"urn:cdx:" <serialNumber> "/" <version> [ "#" <bom-ref> ]
 ```
 
-**Examples**:
-```ini
-urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1
-urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA
-```
+Where:
+- Elements in `""` indicate string literals
+- Elements in `<>` indicate fields
+- Elements in `[]` indicate optionals
 
 | Field        | Description                                                                       |
 | ------------ | --------------------------------------------------------------------------------- |
 | serialNumber | The unique serial number of the BOM. The serial number MUST conform to RFC-4122.  |
 | version      | The version of the BOM. The default version is `1`.                               |
 | bom-ref      | The unique identifier of the component, service, or vulnerability within the BOM. |
 
+**Examples**:
+```text
+urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1
+urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA
+```
+
 There are many use cases that BOM-Link supports. Two common scenarios are:
 * Reference one BOM from another BOM
 * Reference a specific component or service in one BOM from another BOM

CBOM/en/0x80-Cryptography-Definitions.md

@@ -6,18 +6,20 @@ These definitions supports consistent identification, classification, and report
 
 ## Definition structure
 
-The format for each algorithm entry is:
-```
-AlgorithmFamily: Pattern[-{optionalParameter}]
+**Syntax**:
+```text
+<Pattern> ( "[-{" <PatternParameter> "}]" )*
 ```
 
 Where:
-- `AlgorithmFamily` is the algorithm family
-- `Pattern` shows how the algorithm should be referenced
-- Elements in `[]` are optional parameters
-- Elements in `()` indicate choices
-- The `|` symbol indicates alternative choices
-- Elements in `{}` indicate placeholders
+- Elements in `""`  indicate string literals
+- Elements in `<>`  indicate fields
+- Elements in `()*` indicate optionals with cardinality of zero to infinity
+
+| Field | Description |
+| ----- | ----------- |
+| Pattern | shows how the algorithm should be referenced |
+| PatternParameter | shows how the algorithm should be parameterized |
 
 ## Example
 
@@ -76,7 +78,7 @@ The following example defines the P-256 NIST curve, along with its aliases secp2
       "curves": [
         {
           "name": "P-256",
-          "description": null,
+          "description": "...",
           "oid": "1.2.840.10045.3.1.7",
           "form": "Weierstrass",
           "aliases": [

MBOM/en/0x10-Introduction.md

@@ -26,7 +26,7 @@ The information of an MBOM is designed to be compatible with standards such as:
 A few high-level use cases for MBOM and its compatibility with other CycloneDX xBOM types include:
 
 * **Software (SBOM)** - Describe how a software component or service is built and deployed via a Continuous Integration and Continuous Delivery (CI/CD) pipeline.
-  * *This include capturing simple application builds using traditional `Makefiles`  or more complex, multi-tier software using CI/CD platforms such as Jenkins, Tekton, CircleCI, etc.*
+  * *This include capturing simple application builds using traditional `Makefiles` or more complex, multi-tier software using CI/CD platforms such as Jenkins, Tekton, CircleCI, etc.*
 * **Hardware (HBOM)** - Describe how a hardware component or service is manufactured.
 * **Machine Learning (MLBOM)** - Describe the process of training, quantizing, optimizing and deploying ML models.
 * **Data Processing Pipelines** - Describes how data is marshalled, transformed, enhanced, curated, stored, analyzed and used.