Adds Markdown Linter

.dprint.json

@@ -0,0 +1,16 @@
+{
+  "lineWidth": 80,
+  "markdown": {
+    "textWrap": "always",
+    "lineWidth": 80
+  },
+  "includes": ["**/*.md"],
+  "excludes": [
+    "**/node_modules",
+    "**/*-lock.json",
+    "**/target"
+  ],
+  "plugins": [
+    "https://plugins.dprint.dev/markdown-0.16.3.wasm"
+  ]
+}

.github/workflows/markdown-lint.yaml

@@ -0,0 +1,39 @@
+name: Markdown Lint
+
+on:
+  pull_request:
+    paths:
+      - '**/*.md'
+      - '.github/workflows/markdown-lint.yaml'
+      - '.dprint.json'
+
+jobs:
+  markdown-lint:
+    name: Lint Markdown Files
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Rust
+        uses: dtolnay/rust-toolchain@stable
+        with:
+          toolchain: stable
+          components: rustfmt, clippy
+
+      - name: Cache Rust dependencies
+        uses: actions/cache@v4
+        with:
+          path: |
+            ~/.cargo/registry
+            ~/.cargo/git
+            target
+          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
+          restore-keys: |
+            ${{ runner.os }}-cargo-
+
+      - name: Install dprint
+        run: cargo install dprint
+
+      - name: Run dprint check
+        run: dprint check "**/*.md"

README.md

@@ -9,8 +9,9 @@
 # CycloneDX Transparency Exchange API Standard
 
 The Transparency Exchange API is being worked on within the CycloneDX community
-with the goal to standardise the API in ECMA. A working group within ECMA TC54 has been
-formed - TC54 TG1. The working group has a slack channel in the CycloneDX slack space.
+with the goal to standardise the API in ECMA. A working group within ECMA TC54
+has been formed - TC54 TG1. The working group has a slack channel in the
+CycloneDX slack space.
 
 ![](images/tealogo.png)
 
@@ -19,64 +20,98 @@ formed - TC54 TG1. The working group has a slack channel in the CycloneDX slack
 This specification defines a standard, format agnostic, API for the exchange of
 product related artefacts, like BOMs, between systems. The work includes:
 
-- [Discovery of servers](/discovery/readme.md): Describes discovery using the Transparency Exchange Identifier (TEI)
+- [Discovery of servers](/discovery/readme.md): Describes discovery using the
+  Transparency Exchange Identifier (TEI)
 - Retrieval of artefacts
 - Publication of artefacts
 - Authentication and authorization
 - Querying
 
 System and tooling implementors are encouraged to adopt this API standard for
-sending/receiving transparency artefacts between systems. 
-This will enable more widespread
-"out of the box" integration support in the BOM ecosystem.
+sending/receiving transparency artefacts between systems. This will enable more
+widespread "out of the box" integration support in the BOM ecosystem.
 
 ## Use cases and requirements
 
-The working group has produced a list of use cases and requirements for the protocol.
+The working group has produced a list of use cases and requirements for the
+protocol.
 
 - [TEA requirements](doc/tea-requirements.md)
 - [TEA use cases](doc/tea-usecases.md)
 
 ## Data model
 
-- [TEA Product index](tea-index/tea-index.md): This is the starting point. A "product" is something for sale. The [Transparency Exchange Identifier, TEI](/discovery/readme.md) points to a single product.
-- [TEA Leaf index](tea-leaf/tea-leaf.md): A leaf is a version entry. The leaf index has one entry per version of the product.
-- [TEA Collection](tea-collection/tea-collection.md): The collection is a list of artefacts for a specific version. The collection can be dynamic or static, depending on the implemenation.
+- [TEA Product index](tea-index/tea-index.md): This is the starting point. A
+  "product" is something for sale. The
+  [Transparency Exchange Identifier, TEI](/discovery/readme.md) points to a
+  single product.
+- [TEA Leaf index](tea-leaf/tea-leaf.md): A leaf is a version entry. The leaf
+  index has one entry per version of the product.
+- [TEA Collection](tea-collection/tea-collection.md): The collection is a list
+  of artefacts for a specific version. The collection can be dynamic or static,
+  depending on the implemenation.
 
 ## Artefacts available of the API
 
-The Transparency Exchange API (TEA) supports publication and retrieval of a set of transparency exchange artefacts. The API itself should not be restricting the types of the artefacts. A few examples:
+The Transparency Exchange API (TEA) supports publication and retrieval of a set
+of transparency exchange artefacts. The API itself should not be restricting the
+types of the artefacts. A few examples:
 
 ### xBOM
 
-Bill of materials for any type of component and service are supported. This includes, but is not limited to, SBOM, HBOM, AI/ML-BOM, SaaSBOM, and CBOM. The API provides a BOM format agnostic way of publishing, searching, and retrieval of xBOM artifacts. 
+Bill of materials for any type of component and service are supported. This
+includes, but is not limited to, SBOM, HBOM, AI/ML-BOM, SaaSBOM, and CBOM. The
+API provides a BOM format agnostic way of publishing, searching, and retrieval
+of xBOM artifacts.
 
 ### CDXA
 
-Standards and requirements along with attestations to those standards and requirements are captured and supported by CycloneDX Attestations (CDXA). Much like xBOM, these are supply chain artifacts that are captured allowing for consistent publishing, searching, and retrieval.
+Standards and requirements along with attestations to those standards and
+requirements are captured and supported by CycloneDX Attestations (CDXA). Much
+like xBOM, these are supply chain artifacts that are captured allowing for
+consistent publishing, searching, and retrieval.
 
 ### VDR/VEX
 
-Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX) are supported artifact types. Like the xBOM element, the VDR/VEX support is format agnostic. However, CSAF has its own distribution requirements that may not be compatible with APIs. Therefore, the initial focus will be on CycloneDX (VDR and VEX) and OpenVEX.
+Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange
+(VEX) are supported artifact types. Like the xBOM element, the VDR/VEX support
+is format agnostic. However, CSAF has its own distribution requirements that may
+not be compatible with APIs. Therefore, the initial focus will be on CycloneDX
+(VDR and VEX) and OpenVEX.
 
 ### CLE
 
-Product lifecycle events that are captured and communicated through the Common Lifecycle Enumeration will be supported. This includes product rebranding, repackaging, mergers and acquisitions, and product milestone events such as end-of-life and end-of-support.
+Product lifecycle events that are captured and communicated through the Common
+Lifecycle Enumeration will be supported. This includes product rebranding,
+repackaging, mergers and acquisitions, and product milestone events such as
+end-of-life and end-of-support.
 
 ### Insights
 
-Much of the focus on Software Transparency from the U.S. Government and others center around the concept of “full transparency”. Consumers often need to ingest, process, and analyze SBOMs or VEXs just to be able to answer simple questions such as:
+Much of the focus on Software Transparency from the U.S. Government and others
+center around the concept of "full transparency". Consumers often need to
+ingest, process, and analyze SBOMs or VEXs just to be able to answer simple
+questions such as:
 
 - Do any of my licensed products from Vendor A use Apache Struts?
-- Are any of my licensed products from Vendor A vulnerable to log4shell and is there any action I need to take?
+- Are any of my licensed products from Vendor A vulnerable to log4shell and is
+  there any action I need to take?
 
-Insights allows for “limited transparency” that can be asked and answered using an expression language that can be tightly scoped or outcome-driven. Insights also removes the complexities of BOM format conversion away from the consumers. An object model derived from CycloneDX will be an integral part of this API, since the objects within CycloneDX are self-contained (thus API friendly) and the specification supports all the necessary xBOM types along with CDXA.
+Insights allows for "limited transparency" that can be asked and answered using
+an expression language that can be tightly scoped or outcome-driven. Insights
+also removes the complexities of BOM format conversion away from the consumers.
+An object model derived from CycloneDX will be an integral part of this API,
+since the objects within CycloneDX are self-contained (thus API friendly) and
+the specification supports all the necessary xBOM types along with CDXA.
 
 ## Presentations and videos
 
-- You can find presentations in the repository in the [Presentations](/presentations) directory
-- Our biweekly meetings are available on [YouTube playlist: Project Koala](https://www.youtube.com/playlist?list=PLqjEqUxHjy1XtSzGYL7Dj_WJbiLu_ty58)
-- KoalaCon 2024 - an introduction to the project - can be [viewed on YouTube](https://youtu.be/NStzYW4WnEE?si=ihLirpGVjHc7K4bL)
+- You can find presentations in the repository in the
+  [Presentations](/presentations) directory
+- Our biweekly meetings are available on
+  [YouTube playlist: Project Koala](https://www.youtube.com/playlist?list=PLqjEqUxHjy1XtSzGYL7Dj_WJbiLu_ty58)
+- KoalaCon 2024 - an introduction to the project - can be
+  [viewed on YouTube](https://youtu.be/NStzYW4WnEE?si=ihLirpGVjHc7K4bL)
 
 ## Terminology
 
@@ -92,5 +127,33 @@ Insights allows for “limited transparency” that can be asked and answered us
 
 ## Previous work
 
-- [The CycloneDX BOM Exchange API](/api/bomexchangeapi.md)
-   Implemented in the [CycloneDX BOM Repo Server](https://github.com/CycloneDX/cyclonedx-bom-repo-server)
+- [The CycloneDX BOM Exchange API](/api/bomexchangeapi.md) Implemented in the
+  [CycloneDX BOM Repo Server](https://github.com/CycloneDX/cyclonedx-bom-repo-server)
+
+## Contributing
+
+### Markdown Formatting
+
+This repository uses a Rust-based Markdown formatter (dprint) to ensure
+consistent documentation formatting. When submitting pull requests that include
+Markdown files, the formatter will automatically check for formatting issues.
+
+To run the formatter locally:
+
+1. Install dprint:
+   ```bash
+   cargo install dprint
+   ```
+
+2. Check for formatting issues:
+   ```bash
+   dprint check "**/*.md"
+   ```
+
+3. Automatically format all Markdown files:
+   ```bash
+   dprint fmt "**/*.md"
+   ```
+
+The formatter enforces a maximum line length of 80 characters and consistent
+formatting across all Markdown files.

api-flow/consumer.md

@@ -1,24 +1,33 @@
 # Transparency Exchange API: Consumer access
 
-
-The consumer access starts with a TEI, A transparency Exchange Identifier. This is used to find the API server as
-described in the [discovery document](/discovery/readme.md).
+The consumer access starts with a TEI, A transparency Exchange Identifier. This
+is used to find the API server as described in the
+[discovery document](/discovery/readme.md).
 
 ## API usage
 
 The standard TEI points to a product.
 
-- __List of TEA leafs__: Leafs are components of something sold. Each leaf has it's own versioning and it's own set of artefacts. Note that a single artefact can belong to multiple versions of a leaf and multiple leafs.
-- __List of TEA collections__: For each leaf, there is a list of TEA collections as indicated by release date and a version string. The TEA API has no requirements of type of version string (semantic or any other scheme) - it's just an identifier set by the manufacturer. It's sorted by release date as a default.
-- __List of TEA artefacts__: The collection is unique for a version and contains a list of artefacts. This can be SBOM files, VEX, SCITT, IN-TOTO or other documents.
-- __List of artefact formats__: An artefact can be published in multiple formats.
-
-The user has to know product TEI and version of each component (TEA LEAF) to find the list of artefacts for the used version.
+- **List of TEA leafs**: Leafs are components of something sold. Each leaf has
+  it's own versioning and it's own set of artefacts. Note that a single artefact
+  can belong to multiple versions of a leaf and multiple leafs.
+- **List of TEA collections**: For each leaf, there is a list of TEA collections
+  as indicated by release date and a version string. The TEA API has no
+  requirements of type of version string (semantic or any other scheme) - it's
+  just an identifier set by the manufacturer. It's sorted by release date as a
+  default.
+- **List of TEA artefacts**: The collection is unique for a version and contains
+  a list of artefacts. This can be SBOM files, VEX, SCITT, IN-TOTO or other
+  documents.
+- **List of artefact formats**: An artefact can be published in multiple
+  formats.
+
+The user has to know product TEI and version of each component (TEA LEAF) to
+find the list of artefacts for the used version.
 
 ## API flow
 
 ```mermaid
-
 ---
 title: TEA consumer
 ---
@@ -47,7 +56,4 @@ sequenceDiagram
     tea_collection ->> user: List of artefacts and formats available for each artefact
 
     user ->> tea_artifact: Download artefact
-
-
-
 ```

api-flow/publisher.md

@@ -3,7 +3,6 @@
 ## Bootstrapping
 
 ```mermaid
-
 sequenceDiagram
     autonumber
     actor Vendor
@@ -19,7 +18,6 @@ sequenceDiagram
 
     Vendor ->> tea_collection: POST to /v1/collection with the TEA Leaf ID as the and the artifact as payload
     tea_collection ->> Vendor: Collection is created with the collection ID returned
-
 ```
 
 ## Release life cycle
@@ -40,7 +38,6 @@ sequenceDiagram
     Note over Vendor,TEA Leaf: Add an artifact (e.g. SBOM)
     Vendor ->> tea_collection: POST to /v1/collection with the TEA Leaf ID as the and the artifact as payload
     tea_collection ->> Vendor: Collection is created with the collection ID returned
-
 ```
 
 ## Adding a new artifact
@@ -58,4 +55,4 @@ sequenceDiagram
 
     Vendor ->> tea_collection: POST to /v1/collection with the TEA Leaf ID as the and the artifact as payload
     tea_collection ->> Vendor: Collection is created with the collection ID returned
-```
+```