This implementation's answers to the Dextrin Conformance Suite.

The suite runs every DXN implementation against the same cases, reaching each one through its conformance command (mix dextrin.conformance here) with a JSON request, and reading a JSON answer back:

%{"cases" => [%{"id" => "scalars: an integer", "operation" => "decode", "text" => "42"}]}
#=> %{"results" => [%{"id" => "scalars: an integer", "canonical" => "42"}]}

• "decode" reads "text" and answers its canonical form (Dextrin.Canonical, DXN.md §1.5);

• "decode-binary" reads "binary", a base64 .dxnb document, and answers its canonical form;

• "encode" reads "text" and answers the exact .dxnb bytes, as base64.

• "format" reads "text" as a Dextrin.Document and answers it laid out, comments kept (Dextrin.Document.format/2), as "text";

• "edit" reads "text" as a document, makes its "edits" in order, and answers the document rendered, as "text". An edit is {"op": "replace" | "delete" | "insert" | "update", ...} with "path", "value" and "where" written as DXN text, read by this implementation's own decoder; "update" may say "on_ambiguity". A refused edit answers document/not-found, document/exists, document/ambiguous or document/not-a-collection.

A case may carry "schemas", .dxns sources compiled in order into the registry it runs with, and "strict": true, which decodes strictly (DXN.md §4.7).

Any of them may answer "error" instead: the error's category (DXN.md §5), never its message. An error with no category yet is answered as "uncategorised", which no case expects, so it shows up as a disagreement rather than passing by accident.

JSON, not DXN, on purpose: the suite must never read what an implementation said through any implementation's DXN.