Expand product catalog data export with structured fields (in addition to the HTML blob)

Please describe the problem with this page:

https://E4S-Project.github.io/product-catalog/

Summary

I would like to have the product catalog generator emit the data currently packed into each product's html_blob field as separate, structured fields — either alongside the existing blob or as a new export alongside it. This would let the E4S website publish a genuinely useful JSON version of the full catalog for developers and AI tools to consume directly, rather than one that requires decoding and HTML-parsing to get at the actual content.

Background

The E4S website (e4s.io) pulls product-catalog.yml daily and renders it as the Product Catalog page. We'd like to also publish a machine-readable JSON export of this data — for use by developers, tooling, and AI assistants that answer questions about E4S. The clean top-level fields (name, area, description, last_updated) already support this well.

The problem is that almost everything else useful — homepage URL, accelerator support, Spack variants, and the full per-facility deployment matrix — is packed into html_blob, a base64-encoded dump of rendered HTML. To use any of that data programmatically today, a consumer has to base64-decode the field and then parse HTML out of the result, which defeats the point of a structured export.

Current format (example, abbreviated)

{
  "name": "ADIOS2",
  "area": "Data & Viz",
  "description": "I/O and data management library for storage I/O...",
  "html_blob": "PEI+RGVzY3JpcHRpb24...",
  "last_updated": "2026-09-08 23:57:06"
}

Decoding html_blob reveals it contains (as rendered HTML, not structured data):

Homepage URL
Accelerator Support / Accelerator Variants
Spack Smoke Test status
E4S Testsuite Test status
Document Summaries (README/LICENSE/etc., each with a link, an excerpt, and its own "Last Updated")
Product Deployment: a nested tree of facility → cluster → version/compiler/variants/architecture
Requested change

Emit the above as structured fields instead of (or in addition to) html_blob. A rough starting proposal — happy to adjust to whatever's easiest on your end:

{
  "name": "ADIOS2",
  "area": "Data & Viz",
  "description": "I/O and data management library for storage I/O...",
  "homepage": "https://adios2.readthedocs.io",
  "accelerator_support": true,
  "accelerator_variants": ["CUDA", "ROCM", "SYCL"],
  "spack_smoke_test": true,
  "e4s_testsuite_test": true,
  "document_summaries": [
    { "title": "ReadMe.md", "url": "https://github.com/ornladios/ADIOS2/blob/HEAD/ReadMe.md", "last_updated": "2026-09-08 23:57:06", "excerpt": "..." }
  ],
  "deployments": [
    { "facility": "NERSC", "cluster": "cori-22.02", "version": "2.7.1", "compiler": "gcc@11.2.0", "variants": "+blosc+bzip2~dataman...", "architecture": "cray-cnl7-haswell" }
  ],
  "last_updated": "2026-09-08 23:57:06"
}

Why this matters
Lets the E4S website publish a real JSON API for the catalog instead of one that's technically JSON but practically requires an HTML parser to use.
Makes the catalog directly usable by AI coding agents and assistants (e.g. "what does E4S offer for X, and what accelerator variants does it support") without them having to reverse-engineer the blob format.
Keeps the HTML rendering path working exactly as it does today if html_blob stays in place alongside the new fields — this doesn't need to be a breaking change.

Happy to discuss the exact field names/shape if a different structure is easier to generate on your end — the goal is just to get this data out of an encoded HTML blob and into fields a consumer can read directly.