docs: add "Implementations in the wild" section (refs #26, #66) - #71
docs: add "Implementations in the wild" section (refs #26, #66)#71YE-YI7 wants to merge 1 commit into
Conversation
…ards-project#66) Creates the section proposed in ards-project#26 and lists the ASM tool-selection catalog, following the invitation in ards-project#66. Verified with this repo's conformance CLI v0.5.0 against the live endpoint before opening: PASS, 0 critical errors, 30 warnings — all of them the media-type finding that ards-project#66 asks about. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Another candidate for the section when it lands: the Desvela ARD Registry, Verified with this repo's CLI immediately before writing: The registry run failed when I did it this morning, so the honest version of that claim is that it passes as of today: the spec allows an entry to carry its payload inline in I have deliberately not opened a competing PR, since this one creates the section. Happy for it to land as is and to add a row afterwards, or for @YE-YI7 or a maintainer to fold it into this PR, whichever is less work for you. One thing for whoever ends up maintaining the list: Disclosure: I run Desvela. |
|
Thanks @mrenzo20 — Desvela and the independent WellKnownHQ crawler are exactly the kind of evidence that makes an implementations section useful rather than vendor-specific. I have not changed this PR's branch without maintainer direction, but either row can be folded in here or added immediately after merge. One factual update on the ASM row now that its reproduction path exists:
conformance/bin/conformance-test manifest https://asm-spec.onrender.com/.well-known/ai-catalog.jsonNo normative field or allowlist change is requested by this PR. This is my one follow-up; I will leave the listing and candidate rows with maintainers from here. |
Creates the
Implementations in the wildsection proposed in #26, and adds the ASM tool-selection catalog to it — following @mindpower's invitation in #66.Per the README's contribution split this is a non-normative documentation change (no edits to
spec/ard.mdorspec/schemas/), so I'm opening it directly as a PR rather than an issue.Conformance
Verified against the live endpoint with this repo's CLI (v0.5.0) immediately before opening:
All 30 warnings are the same finding —
Media type 'application/asm+json' is not one of standard discovery types— which is exactly what #66 asks about. I've noted that inline in the table rather than leaving it implicit, so the row doesn't read as a clean bill of health while that question is still open. If you'd rather the section only list types already in the allowlist, I'm happy to drop the row until #66 is resolved.One more caveat, also in the table: the catalog is hosted on a free tier that sleeps when idle, so the first request after a quiet period can be slow or need a retry. Flagging it up front so a timeout doesn't get read as a dead endpoint.
On #26
#26 proposed this same section back in June for five conformance-tested deployments (SnowSure, SnowData, Afore, LUXSKI, Ski Limone), and the section itself doesn't appear to have landed — so this PR creates it.
I've deliberately not added those five, since their conformance status isn't mine to assert. @mikeslone — happy to include them in this PR if you'd like, or maintainers can land them separately. Placement, ordering, and wording are all yours to change; I have no attachment to the table format.
(Implementation and this PR drafted with Claude, at my direction and with my approval.)