Konformität
DXN hat vier Implementierungen und eine Spezifikation. Zwei Teile der Spezifikation gibt es, damit sie sich exakt vergleichen lassen: eine kanonische Textform für jeden Wert und eine Kategorie für jeden Fehler. Eine gemeinsame Sammlung von Fällen misst jede Implementierung an beidem.
Die kanonische Form
Jeder Wert hat genau eine kanonische Form: eine .dxn-Darstellung, die bis aufs Byte festgelegt ist. Jede Implementierung muss sie erzeugen können, und sie zu parsen ergibt einen gleichen Wert. Sie legt auch fest, wann zwei Map-Schlüssel derselbe sind.
- Keine Kopfzeile, keine Kommentare, kein
@_; ein Leerzeichen zwischen Elementen oder Einträgen, keines innerhalb der Klammern, keine Kommas, keine Zeilenumbrüche. - Maps und Mengen stehen in kanonischer Reihenfolge: die kanonischen Formen ihrer Einträge oder Elemente, nach Unicode-Codepoint verglichen. Geordnete Maps und Structs behalten ihre eigene Reihenfolge.
- Nichts wird normalisiert:
1.50Mbleibt1.50M,2/4bleibt2/4. - Gleitkommazahlen werden als die kürzesten Ziffern geschrieben, die wieder dasselbe Double ergeben, mit den Schwellen von ECMAScript für den Exponenten,
.0an ganzen Zahlen und ohne+im Exponenten. - Zeichenketten maskieren
",\, Zeilenumbruch, Tabulator und Wagenrücklauf als\",\\,\n,\t,\r, jedes andere Steuerzeichen als\x{…}in kleinen Hex-Ziffern, und sonst nichts. - Zeiten verlieren nachgestellte Nullen im Bruchteil; UUIDs stehen in Kleinbuchstaben; Bytes in Standard-Base64 mit Auffüllung; eine Dauer aus lauter Nullen ist
PT0S; ein Struct trägt(N), wenn seine Version bekannt ist.
%{b: 2, a: 1, "z" => 3}%{"z" => 3 a: 1 b: 2}[1e3 1e21 1.5e-7 0.000001 -0.0 1.50M 2/4 ~T[12:30:00.500] @duration "P0D"]
[1000.0 1.0e21 1.5e-7 0.000001 -0.0 1.50M 2/4 ~T[12:30:00.5] @duration "PT0S"]
Fehlerkategorien
Implementierungen melden Fehler auf ihre eigene Art, aber jeder Fehler, den ein Leser, Schreiber oder Schema-Compiler auslöst, gehört zu genau einer Kategorie, und die Implementierung muss sie am Fehlerwert zugänglich machen. Kategorien werden exakt verglichen; Meldungstexte gehören nicht zur Spezifikation.
| Kategorie | Ausgelöst, wenn |
|---|---|
syntax | Text sich nicht parsen lässt |
binary | ein .dxnb-Dokument fehlerhaft ist: Kennung, Version, Inhalt eines Tags |
key/not-allowed | ein Map- oder Zusatzfeld-Schlüssel einen Typ hat, der kein Schlüssel sein darf |
encode/unsupported | ein Wert der Host-Sprache keine DXN-Bedeutung hat oder keine Form im geschriebenen Text |
schema/compile | ein .dxns-Dokument kein gültiges Schema ist |
schema/duplicate-version | ein Name mit Version zweimal geladen wird |
schema/not-loaded | ein Ersetzen eine nicht geladene Version nennt |
schema/unknown-version | die Version eines Structs älter als die neueste geladene und selbst nicht geladen ist |
schema/no-materializer | eine ältere Version ankommt und kein Materializer registriert ist |
schema/field-count | ein positionelles Struct die falsche Anzahl Elemente für seine Version hat |
schema/missing-field | ein Pflichtfeld fehlt oder eine positionelle Form keinen Wert für ein optionales Feld ohne Standardwert hat |
schema/type-mismatch | der Wert eines Felds nicht zu seinem deklarierten Typ passt |
schema/undeclared-field | striktes Dekodieren auf ein Feld trifft, das das Schema nicht deklariert |
schema/shadowed-field | ein zusätzliches Feld den Namen eines deklarierten trägt |
schema/materializer | ein Materializer ablehnt oder einen Wert liefert, den das neueste Schema abweist |
schema/version-discipline | die Kompatibilitätsprüfung geänderten Inhalt unter derselben Version findet oder eine sinkende Version |
Die Konformitäts-Suite
Die Dextrin Conformance Suite ist eine Sammlung von Fällen, die jeweils eine Operation, ihre Eingabe und das eine erwartete Ergebnis nennen: eine kanonische Form, exakte Bytes, den Text eines Dokuments oder eine Fehlerkategorie. Ihre Fälle decken Skalare, Gleitkommazahlen, Map-Schlüssel, Structs, zusätzliche Felder, Schemas, Binärform und Dokumente ab. Jede Implementierung bringt einen Adapter mit, der einen Stapel Fälle beantwortet — in dextrin mix dextrin.conformance REQUEST ANSWER —, und jede Antwort wird exakt verglichen.
Anfragen und Antworten sind JSON, und die geprüften Werte bleiben DXN-Text oder .dxnb-Bytes; die Suite hängt also von keiner DXN-Implementierung ab, auch von keiner der vier. Sie liegt vorerst im Praxis-Arbeitsbereich und soll in ein eigenes Repository umziehen.