Ein tiefer Blick auf JSON vs. XML, Teil 3: XML und die Zukunft von JSON

In Teil 2 dieses Artikels haben wir uns JSON als Datenaustausch genauer angesehen und seine Stärken und Schwächen für einfache Anwendungen im Vergleich zu komplexen bewertet. JSON zeichnet sich als das prägnanteste und kompakteste menschenlesbare Format aus, aber seine grundlegende Einfachheit kann zu unbeabsichtigten Auswirkungen führen, wenn es für komplexe Anwendungsfälle verwendet wird. Mit JSON als Datenaustausch sind Entwickler auf sich allein gestellt, um die Funktionalitäten zu implementieren, die JSON selbst fehlen, was zu gekoppelten und nicht standardmäßigen Lösungen führt, die versuchen, die Lücke zu schließen. Bei Unternehmenslösungen, die darauf bedacht sind, einen fehlerfreien Betrieb sicherzustellen, kann die Verwendung von JSON zu unerwünschten Mustern führen, die die Codequalität, Stabilität und Widerstandsfähigkeit des Systems gegenüber zukünftigen Unbekannten beeinträchtigen können. Bietet XML Funktionen, mit denen Anwendungen dieses Risiko mindern können? Können die gleichen Funktionalitäten mit JSON erreicht werden? Ein genauerer Blick auf XML als Datenaustausch wird seine Stärken bei der Reduzierung von Softwarerisiken offenbaren und Entwicklern ein besseres Verständnis der Muster vermitteln, die zur Verbesserung der Qualität ihrer Anwendungen beitragen könnten.

In Teil 3 dieses Artikels werden wir:

1. Erkunden Sie XML als Datenaustausch und bewerten Sie seine Stärken bei der Unterstützung komplexer Anforderungen.
2. Diskutieren Sie die Zukunft von JSON und erkunden Sie Lösungen, die die Stärken von XML in JSON einbringen, damit Entwickler Software entwickeln können, die stabiler und widerstandsfähiger gegen Fehler und zukünftige Unbekannte ist.

XML wird gerne als die komplexe und ausführliche Alternative zu JSON bezeichnet. Die Website w3schools.com – eine beliebte Referenz für Webstandards – bietet nur 58 Wörter zum Thema „Warum JSON besser als XML ist“ ¹ . Eine solch vereinfachende Bewertung von JSON vs. XML ist irreführend, da XML viel mehr bietet als nur den Datenaustausch. Tatsächlich wurde XML nicht nur für den Datenaustausch entwickelt, sondern vielmehr als Sprache, um benutzerdefinierte Auszeichnungssprachen für jede Anwendung anzugeben. Mit seiner strengen Semantik hat XML einen Standard definiert, um die Datenintegrität von XML-Dokumenten jeder XML-Untersprache zu gewährleisten. Viele Entwickler glauben, dass „XML fehlschlug und durch JSON ersetzt wurde“, aber das könnte nicht weiter von der Wahrheit entfernt sein. Ursprünglich sollte XML für alle Dateninteroperabilitätsprobleme verwendet werden und ist bis heute „das weltweit am weitesten verbreitete Format zur Darstellung und zum Austausch von Informationen“. ²

JSON ist einfach und XML ist leistungsstark

In Teil 2 dieses Artikels haben wir den Datenaustausch unter Einbeziehung verbrauchergesteuerter Verträge (CDCs), der Protokollentwicklung und der Nachrichtenvalidierung untersucht. Mit JSON als Datenaustausch wurde unser Beispiel – die Europäische Bank – herausgefordert, eine risikomindernde Lösung für den Datenaustausch mit Einzelhändlern bereitzustellen. Die Bank wünschte sich Softwaremuster, die zu einer geringen Kopplung, einer hohen Kapselung und einer hohen Widerstandsfähigkeit gegenüber zukünftigen Unbekannten führten. Mit JSON als Datenaustausch wurden der Bank jedoch Muster präsentiert, die zum Gegenteil führten: geringe Kapselung, hohe Kopplung und eine geringere Widerstandsfähigkeit gegenüber zukünftigen Unbekannten.

Betrachten wir das Beispiel der Europäischen Bank noch einmal und ersetzen JSON als Datenaustauschformat durch XML. Die folgenden XML-Nachrichten entsprechen der JSON-Nachricht für jeden Kontokennungstyp: SWIFT, IBAN und ACH.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

Trotz des unmittelbaren Verlustes an Effizienz bei der Zählung von Rohbytes rechtfertigt XML seine Ausführlichkeit, indem es einen breiteren Bereich rund um den Datenaustausch unterstützt. Durch die Codierung der Daten mit JSON konnten wir die unmittelbaren Anforderungen des Datenaustauschs lösen, aber nichts, um mehrere Nachrichtenvarianten oder deren Validierung zu unterstützen. Um den Umfang verbrauchergesteuerter Verträge zu berücksichtigen, müssten Entwickler benutzerdefinierten Code implementieren, der zu einer logischen Kopplung zwischen dem Nachrichtenformat, seinem Inhalt und der funktionalen Implementierung für seine Verarbeitung führen würde. Alternativ könnte sich der Entwickler entscheiden, ein Puzzle aus einer Sammlung von Bibliotheken und Frameworks zusammenzusetzen, um die höheren Anforderungen zu erfüllen. Beide Ansätze führen zu einer Vielzahl von Schichten über dem Datenaustausch, die direkt mit der Anwendung gekoppelt sind. Durch die Kodierung der Daten mit XML sind wir jedoch in der Lage, viele der Anforderungen ohne Kopplung zu lösen.

Die Äquivalente zu XML-Nachrichten verwenden zwei besondere Merkmale des XML-Standards: Namespaces und Instanztypen. Das Attribut xmlns="urn:bank:message" gibt den Namespace der Nachricht an, und das Attribut "xsi:type" gibt den Instanztyp als "swift" , "iban" oder "ach" an. Diese beiden Attribute sind XML-Standards, die es einem Nachrichtenprozessor ermöglichen, den Typ der Nachricht zu identifizieren sowie das Schema zu dereferenzieren, das die Validierungsregeln definiert.

Das XML-Schema stellt das wesentliche Unterscheidungsmerkmal zwischen JSON und XML dar. Mit einem Schema kann ein Entwickler die normative Definition des Nachrichtenformats in einem von der Anwendung getrennten Medium einkapseln und Wertbeschränkungen definieren, die Validierungsregeln bereitstellen, die von XML-Prozessoren durchgesetzt werden. Ein Beispielschema für die Europäische Bank (mit namespace: xmlns="urn:bank:message" ), komplett mit Typdeskriptoren und Wertbeschränkungen, ist das folgende XML-Schemadokument (XSD):

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

Dieses XML-Schema ist logisch äquivalent zur Funktion isValid(message) aus Teil 2. Auf den ersten Blick ist dieses XML-Schema wesentlich ausführlicher als isValid(message) . Der grundlegende Unterschied zwischen den beiden besteht jedoch darin, dass isValid(message) an die Anwendung gekoppelt ist und das XML-Schema nicht. Das XML-Schema ist eine Sprache zum Ausdrücken von Einschränkungen für XML-Dokumente, und es gibt mehrere verschiedene Schemasprachen, die weit verbreitet sind, von denen die wichtigsten sind: Dokumenttypdefinitionen (DTDs), Relax-NG, Schematron und W3C-XML-Schemadefinitionen (XSD ). ³ Für die Europäische Bank bietet das XML-Schema eine risikoreduzierte Lösung für Anforderungen höherer Schichten ohne die Kopplung.

Ein XML-Schema führt zu einem geringeren Softwarerisiko. Bei XML werden die Regeln für die Validierung von Nachrichten in einer Schemasprache ausgedrückt, die von der Anwendung getrennt und daher nicht mit ihr gekoppelt ist. Da das XML-Schema vollständig vom System losgelöst ist, sind die logische Bedeutung des Nachrichtenformats und die funktionale Implementierung zu seiner Verarbeitung entkoppelt. Das XML-Schema gibt der Europäischen Bank eine gekapselte Ebene, die allein für den Kontext der Nachrichtenvalidierung, Variabilität, Versionierung und mehr verantwortlich ist.

Das XML-Schema repräsentiert die normative Definition des verbrauchergesteuerten Vertrags. Für die Europäische Bank bietet dies einen risikomindernden Ansatz, um $\xi_0$ näher an 0 zu reduzieren. Da das Schema von der Bank und dem Einzelhändler entkoppelt ist, können beide Parteien es verwenden, um den Vertrag zu validieren und durchzusetzen.

Warum ist das XML-Schema so ausführlich?

Die XML-Schemaspezifikation stellt eine Sprache für Entwickler bereit, um strukturelle und logische Muster zu implementieren, die verwendet werden, um alle Bestandteile eines XML-Dokuments zu definieren und einzuschränken. Mit einem XML-Schema können Entwickler tiefere Bedeutungen in jeden strukturellen und logischen Teil eines XML-Dokuments einbetten. Beispielsweise ermöglicht das XML-Schema Folgendes:

1. Definition von Einschränkungen für reguläre Ausdrücke für konstituierende Zeichenfolgen,
2. Definition von Bereichen und Formaten für konstituierende Nummern,
3. Definition erforderlicher und optionaler Bestandteile und Attribute,
4. Definition von Schlüssel- und Referenzanforderungen in einem Dokument und vieles mehr.

Mit einem XML-Schema kann sich ein System auf generische XML-Validatoren verlassen, um die Gültigkeit jeder Eingabenachricht zu bestätigen, wodurch der „Fehlerraum“ $\xi_0$ von Natur aus näher an 0 reduziert und die Geschäftslogik automatisch von fehlerhaften Eingaben isoliert wird.

Das Risiko der zukünftigen Entwicklung

Systeme können inhärente Merkmale der XML-Spezifikation nutzen, um das Softwarerisiko zukünftiger Entwicklungen zu reduzieren. Durch Vereinbarung eines normativen Vertrags in Form eines XML-Schemas definieren Systeme die Regeln und Einschränkungen für alle auszutauschenden Objekte und Eigenschaften (Elemente und Attribute bei XML). Die Systeme sind danach in der Lage, den breiteren Umfang der XML-Spezifikation zu nutzen, um Nachrichtenvariabilität, Protokollversionierung und Inhaltsvalidierung zu berücksichtigen. Beispielsweise stellen XML-Namespaces XML-Nachrichten mit den Informationen bereit, die für Folgendes erforderlich sind:

1. Identifizieren Sie die Version der Nachricht.
2. Dereferenzieren Sie das normative Vertragsschema.
3. Überprüfen Sie die Korrektheit eines Dokuments.

Mit der breiten Palette an Funktionen und Fähigkeiten, die das XML-Schema bietet, können die meisten der komplexen Anforderungen rund um den Datenaustausch mit XML selbst gelöst werden. Darauf bezog sich Dr. Charles Goldfarb, als er sagte: „[XML ist] der heilige Gral der Datenverarbeitung.“ ⁴

Das XML-Schema trägt dazu bei, dass Anwendungen fehlerresistent und an zukünftige Änderungen anpassbar sind.

XML ist eine weithin akzeptierte und gründlich geprüfte Spezifikation mit unzähligen Bibliotheken, die für alle Plattformen verfügbar sind, um die Verarbeitung und Validierung von XML-Dokumenten zu unterstützen. Mit XML als Datenaustauschformat ist ein Entwickler in der Lage, sowohl die unmittelbaren Anforderungen als auch diejenigen in Bezug auf verbrauchergesteuerte Verträge, Nachrichtenvariabilität, Protokollversionierung und Inhaltsvalidierung zu lösen. XML ermöglicht es einem Entwickler, das Risiko komplexer Anforderungen und, was noch wichtiger ist, zukünftiger Unbekannter abzusichern.

XML ist viel mehr als nur Datenaustausch und kann verwendet werden, um viel größere Probleme anzugehen als mit JSON. Aus dieser Perspektive betrachtet deckt der Geltungsbereich von XML einen größeren Teil der Zwiebel ab, wobei mehrere Schichten der Zwiebel im Geltungsbereich von XML selbst enthalten sind.

Ist bei der Auswahl des besten Datenaustauschformats für eine Anwendung nur das Zentrum der Zwiebel wichtig, oder ist es die Zwiebel als Ganzes?

Die grundlegenden Unterschiede zwischen JSON und XML

XML bietet viel mehr als nur Datenaustausch und kann verwendet werden, um viel größere Probleme anzugehen als mit JSON. Dem Umfang komplexer Anforderungen rund um den Datenaustausch wird durch XML Rechnung getragen, wodurch Systeme standardkonforme Bibliotheken und Frameworks nutzen können, die von der Anwendung entkoppelt sind.

XML ist eine Spezifikation, die den Umfang komplexer Anforderungen durch Design adressiert und ein vom W3C definierter Standard ist, der von allen relevanten Softwareanbietern und Sprachplattformen unterstützt wird. Durch die Verwendung von XML als Datenaustausch profitieren Anwendungen automatisch von einer systematischen Reduzierung des Softwarerisikos.

Die Zukunft von JSON

JSON ist zweifellos hier, um zu bleiben. Da JavaScript heute die am weitesten verbreitete Entwicklungsplattform ist, hat sich JSON zum bekanntesten Datenaustauschformat entwickelt. Für kleine Projekte mit geringer Komplexität ist JSON perfekt geeignet. Da wir uns jedoch bemühen, größere und bessere Anwendungen für die Zukunft zu entwickeln, wird die allgemeine Komplexität unserer Software zunehmen. Mit den leistungsstarken Fähigkeiten von XML als Beispiel haben sich mehrere Gruppen bemüht, ähnliche Standards für JSON zu erfinden.

Der grundlegende Mangel von JSON ist das Fehlen eines allgemeinen Standards für die normative Beschreibung der logischen Bestandteile seiner Dokumente.

JSON-Schema

Im Jahr 2009 startete eine Gruppe das JSON-Schema ⁵ , ein Vokabular zum Kommentieren und Validieren von JSON-Dokumenten. Das JSON-Schema verwendet die JSON-Semantik, um eine Reihe von Regeln und Einschränkungen für Bestandteile von JSON-Dokumenten zu definieren, und mehrere Projekte auf verschiedenen Plattformen haben Bibliotheken implementiert, die die JSON-Schemaspezifikation unterstützen. Obwohl es noch kein offizieller Standard ist, bietet das JSON-Schemaprojekt eine Lösung für einen Umfang von Anforderungen, der der XML-Schemaspezifikation ähnlich ist. Mit dem JSON-Schema-Vokabular können Entwickler die logischen und strukturellen Regeln und Einschränkungen von JSON-Dokumenten definieren. Das Schema kann dann verwendet werden, um die Verarbeitung und Validierung von JSON-Dokumenten mit Bibliotheken zu unterstützen, die von der Anwendung entkoppelt sind, wodurch die Notwendigkeit reduziert wird, nicht gekapselten Code in die Anwendung einzumischen. Mit dem JSON-Schema kann ein Entwickler JSON als Format seines Datenaustauschs wählen und auf risikoreduzierte Weise die komplexen Anforderungen adressieren, die bisher nicht mit JSON allein adressiert werden konnten.

Das JSON-Schemaprojekt ist eine Gemeinschaftsleistung und gilt nach einem Jahrzehnt der Überarbeitung als die vorherrschende Spezifikation für JSON-Schemas. Obwohl es noch kein Standard ist, zeigt die Popularität des JSON-Schema-Projekts das Interesse an einer solchen Lösung. Konzeptionell ähnelt die JSON-Schemaspezifikation dem XML-Schema, aber ein Vergleich der beiden offenbart Unterschiede zwischen ihren Modellen, Fähigkeiten und Semantiken. Obwohl die Sprache beispielsweise eine breite Palette von Eigenschaften definiert, um die Grenzen von JSON-Werttypen einzuschränken, ermöglichen ihre zahlreichen Attribute den Ausdruck von sich widersprechenden Schemadefinitionen.

Der folgende Auszug definiert beispielsweise einen "object" -Typ, der drei Eigenschaften enthält: "number" , "street_name" und "street_type" .

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

Die Definition eines "object" -Typs akzeptiert zusätzliche Einschränkungen, von denen eine "minProperties" ist. Durch das Modifizieren der obigen Typdefinition "object" mit einem "minProperties": "4" wird die Definition unsinnig, da nur drei Eigenschaften explizit für das Objekt definiert sind.

Das JSON-Schema verfügt über eine beträchtlich große und große Anzahl von Einschränkungseigenschaften, von denen viele unerlässlich sind, um JSON-Dokumente effektiv einzuschränken, und von denen sich viele überschneiden. Mit Beschränkungseigenschaften, die sich in ihrer Bedeutung überschneiden, stellt das JSON-Schemavokabular zwei Arten von Herausforderungen dar:

1. Aufgrund des breiten Vokabulars und der ungewöhnlichen oder unkonventionellen Nuancen in seiner Semantik erfordert es von Entwicklern eine höhere Lernkurve.
2. Die Implementierung von Validierungsbibliotheken ist schwieriger, was zu Lösungen führt, die die Graubereiche unterschiedlich implementieren, was zu inkonsistenten Implementierungen führt.

Die XML-Schemasprache selbst ist nicht völlig frei davon, den Ausdruck widersprüchlicher Definitionen zuzulassen, aber sie sind viel weniger und begrenzt. Tatsächlich wurde die XML-Schema-Spezifikation unter besonderer Berücksichtigung der Benutzerfreundlichkeit sowohl für Entwickler als auch für Bibliotheken entwickelt, die die Spezifikation implementieren. Darüber hinaus definiert das JSON-Schemaprojekt nur die Spezifikation der Schemasprache, aber es gibt viele Community-Projekte, die diese Spezifikation implementieren.

Der JSON-Schema-Validator ⁶ ist ein beliebtes Projekt, das einen JSON-Schema-Validator für die Java-Plattform implementiert. Durch die Integration dieser Bibliothek in eine Java-Anwendung kann die Anwendung die Konformität aller ausgetauschten JSON-Dokumente bestätigen. Andere Implementierungen der JSON-Schemaspezifikation sind für eine Vielzahl von Plattformen verfügbar.

Verwenden wir für die Europäische Bank das JSON-Schema, um ein Schema für JSON-Nachrichten mit Kontokennungen zu implementieren.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

Dieses JSON-Schema definiert die 3 Objekttypen: "swift" , "iban" und "ach" . Es gibt reguläre Ausdrucksmuster an, um sicherzustellen, dass die Kontoinformationen nicht ungültig sind, und deklariert "type" und "code" als erforderliche Eigenschaften für jeden Typ, zusätzlich zu "routing" als erforderliche Eigenschaft für den Typ "ach" . Mit diesem JSON-Schema kann die Europäische Bank ihre JSON-Eingabe validieren, um sicherzustellen, dass der Nachrichteninhalt für jede Interaktion korrekt ist.

Das JSON-Schema bringt viele Funktionen von XML in JSON, ist aber noch in Arbeit. Obwohl es sich um eine großartige Lösung zur Absicherung von Softwarerisiken handelt, ist die JSON-Schemaspezifikation nicht perfekt. Aufgrund der informellen Entwicklung ihrer Sprache hat sich die Sprache in eine Richtung entwickelt, die wohl wichtige Merkmale auslässt und strukturelle und logische Ausdrucksmuster enthält, die verwirrend und unkonventionell sind. Beispielsweise fehlt der Schemasprache die Fähigkeit, abstrakte Typen zu definieren, was dazu führen kann, dass Entwickler komplizierte Problemumgehungen implementieren, die zu einem damit verbundenen eigenen Softwarerisiko führen. ⁷

Das JSON-Schemaprojekt hat einen unschätzbaren Beitrag zu den Konzepten hinter einer Schemasprache für JSON geleistet. Trotz der Mängel in der Klarheit ihrer Semantik ist die JSON-Schemasprache eine vielseitige Lösung, die viele Möglichkeiten von XML in JSON bringt.

Eine genauere Betrachtung der JSON-Schemaspezifikation finden Sie unter Grundlegendes zum JSON-Schema.

JSONx

Im Jahr 2014 startete eine andere Gruppe das JSONx-Projekt, das XML direkt nutzt, um eine ebenso leistungsstarke Lösung für JSON bereitzustellen. Das JSONx-Projekt wurde speziell für Unternehmen erstellt und definiert die JSON-Schemadefinitionssprache (JSD), die eng an die XML-Schemaspezifikation angelehnt ist. Unter Verwendung des XML-Schemas als Modell definiert das JSD strukturelle und logische Muster, die der XML-Schema-Definitionssprache sehr ähnlich sind.

Verwenden wir für das Beispiel der Europäischen Bank die JSD-Sprache, um ein Schema für JSON-Nachrichten mit Kontokennungen zu implementieren.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

Auf den ersten Blick ähnelt das JSD-Schema im Ausdruck dem JSON-Schema. Ein Unterschied ist jedoch die prägnante Semantik des JSD im Vergleich zum JSON-Schema. Speziell für dieses Beispiel platziert die JSD die Eigenschaft "use": "required" in der angegebenen Definition, während das JSON-Schema diese Eigenschaft dem übergeordneten Objekt zuordnet und erfordert, dass der Name der Werte mit dem Namen der Eigenschaftsdefinition übereinstimmt. Die Einschränkung "use": "required" wird nur für die Eigenschaft "code" des Objekts "swift" angegeben und bei den anderen weggelassen, da "use": "required" der Standardwert ist. Die JSD-Sprache wurde unter genauer Berücksichtigung all dieser Nuancen entwickelt und bietet eine saubere und intuitive Lösung für den Ausdruck von JSON-Schemas.

Von Anfang an ist eine charakteristische Eigenschaft des JSONx-Projekts seine primäre Absicht, Entwicklern Klarheit und Nützlichkeit zu bieten. Um dies zu erreichen, ist eine leistungsstarke Funktion des JSD seine Konvertierbarkeit in JSDx – die JSD-Sprache kann sowohl in JSON-Dateien als auch in XML-Dateien ausgedrückt werden. Beide Formulare sind eins-zu-eins übersetzbar und bieten Entwicklern die Möglichkeit, fortschrittliche XML-Bearbeitungstools zu verwenden, um die Erstellung von JSD-Dokumenten zu unterstützen, die live validiert und fehlerfrei sind.

Das JSD-Schema von oben kann in der folgenden JSDx-Form ausgedrückt werden:

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

Die JSDx-Form der JSD ist leistungsstark, da sie eine klare, selbstvalidierende und risikoreduzierte Spezifikation zum Definieren von JSON-Schemas bereitstellt.

Die JSD-Sprache wurde entwickelt, um Bedenken hinsichtlich sich widersprechender Definitionen zu berücksichtigen, und stützt sich auf Standardmuster für den Ausdruck von Einschränkungen. Die JSD-Typdeklarationen und -Definitionen von Einschränkungen wurden in enger Anlehnung an die XML-Schemadefinitionssprache (XSD) entwickelt und ähneln äquivalenten Strukturen in XML. Die JSD(x)-Spezifikation bietet eine vollständige Lösung für die Definition struktureller und logischer Einschränkungen und ist selbstbeschreibend – sie stellt eine normative Definition der JSD(x)-Sprache bereit, die in der JSD(x)-Sprache selbst ausgedrückt wird. Einen genaueren Blick auf die JSD(x)-Spezifikation finden Sie unter JSON Schema Definition Language.

Zusätzlich zur JSD(x)-Sprache bietet das JSONx-Projekt Referenzimplementierungen von JSD(x)-Prozessoren und -Validatoren sowie eine Klassenbindungs-API und einen Codegenerator für die Java-Plattform. Mit der Bindungs-API und dem Generator kann ein Entwickler ein JSD(x)-Schema verwenden, um automatisch Klassen für die Objektdefinitionen im gewünschten Schema zu generieren, die zum Analysieren und Marshallen von JSON-Dokumenten verwendet werden können, die dem Schema entsprechen. Die generierten Klassen stellen eine stark typisierte Bindung zwischen dem Schema und der Java-Plattform bereit, die die Verwendung, Einschränkungen und Beziehungen darstellen, die im Schema angegeben sind. Mit stark typisierten Bindungen an das Schema reduziert die Anwendung das Softwarerisiko in Bezug auf zukünftige Änderungen, die zu Inkompatibilitäten führen könnten, weiter.

Durch die Nutzung des Java-Compilers lokalisieren stark typisierte Bindungen die Inkompatibilitäten mit Kompilierzeitfehlern und reduzieren das Risiko für Fehler bei der Nachrichtenverarbeitung effektiv auf nahezu Null. Dieses Konstruktionsmuster ermöglicht es Entwicklern, Änderungen schnell und sicher zu implementieren und Inkompatibilitäten zu beheben, ohne sich auf die Laufzeit verlassen zu müssen, um Fehler oder Fehlerfälle zu finden – und insbesondere nicht darauf, dass Benutzer selbst über die Fehler stolpern. Die Bindungs-API ist mit Java-Annotationen implementiert, wodurch jede Klasse mit starken Typen und dennoch leichtgewichtig an ein JSD(x)-Schema gebunden werden kann. Die stark typisierten Bindungs- und Codegenerierungsfunktionen von JSONx unterstützen den vollen Umfang der JSD(x)-Spezifikation, die speziell entwickelt wurde, um die hohen Standards für Unternehmenslösungen zu erfüllen.

Das JSONx-Framework wurde für Unternehmenslösungen entwickelt und bietet einen hohen Standard an Qualität und Nützlichkeit für komplexe Systeme sowie Benutzerfreundlichkeit und Fehlervalidierung während der Bearbeitung für Entwickler.

Die JSD(x)-Binding-Engine, der Prozessor und der Validator melden eine Testabdeckung von 87 %, sodass Java-Entwickler das Framework vertrauensvoll integrieren können, um JSD(x)-Schemas an ihre Java-Anwendungen zu binden und JSON-Dokumente zu codieren, zu decodieren und zu validieren. Einen genaueren Blick auf das JSONx-Framework für Java finden Sie unter JSONx Framework for Java.

Fazit

Wenn wir uns die Geschichte des Webs und der Softwaretrends der letzten Jahre genauer ansehen, können wir eine enge Beziehung zwischen der Verbreitung von JavaScript und der Popularität von JSON erkennen. Viele Artikel und Blog-Beiträge bieten eine begrenzte Perspektive beim Vergleich von JSON und XML, was Leser dazu veranlasst, XML als veraltet abzutun, und viele leistungsstarke Funktionen nicht kennen, die ihnen helfen können, die Architektur ihrer Software, die Widerstandsfähigkeit ihrer Software gegenüber Änderungen und die Gesamtqualität zu verbessern Stabilität der Software als Ganzes. Mit einer tieferen Bewertung der Stärken und Schwächen jedes Standards können Entwickler in die Lage versetzt werden, bessere Entscheidungen für ihre Projekte zu treffen.

Wie die „Divergenzkatastrophe“ mit HTML, die zur Erfindung von XML führte, wird ein ähnlicher Effekt in komplexen Codebasen realisiert, die für den Datenaustausch auf JSON angewiesen sind. Die JSON-Spezifikation kapselt nicht die unmittelbaren Funktionalitäten rund um den Datenaustausch, was zu einer Fragmentierung der Logik in den höheren Schichten der Anwendung führen kann. Mit XML sind Entwickler jedoch in der Lage, die Komplexität des Datenaustauschs auf die unteren Schichten der Anwendung zu verlagern, was dazu führt, dass Fehler früher im Lebenszyklus der Anwendung erkannt werden. Insbesondere für kompilierte Sprachen können Architekturen, die auf XML-Bindung basieren, in Kombination mit einem Binding Framework das Potenzial für datenbezogene Fehler auf nahezu Null reduzieren. Für Unternehmen sind es diese leistungsstarken Funktionen zur systematischen Reduzierung von Softwarerisiken, die XML zum „Heiligen Gral der Datenverarbeitung“ machen.

JSON ist hier, um zu bleiben, und mehrere Projekte gewinnen an Dynamik, um JSON die leistungsstarken Funktionen von XML anzubieten. Das JSON-Schemaprojekt bietet eine von der Community entwickelte Schemaspezifikation, die organisch gewachsen ist, um eine breite Palette von Attributen und deklarativen Mustern zum Beschreiben und Einschränken von JSON-Dokumenten zu unterstützen. Das JSONx-Projekt stellt eine Schemasprache für Unternehmen bereit, die der XML-Schemadefinitionssprache sehr ähnlich ist und sowohl JSON- als auch XML-Formate für die Spezifikation von JSON-Schemadokumenten bietet. Mit diesen Spezifikationen und Frameworks sind Entwickler in der Lage, Softwarerisiken im Zusammenhang mit Anforderungen höherer Schichten rund um den Datenaustausch zu reduzieren, wie z. B. verbrauchergesteuerte Verträge, Protokollversionierung, Inhaltsvalidierung und mehr.

Die erweiterten Funktionen von XML wurden entwickelt, um das Softwarerisiko im Zusammenhang mit Auszeichnungssprachen zu mindern. Anwendungsfälle mit JSON sind nicht anders, und eine Schemasprache ist eine erprobte und bewährte Lösung, um das breite Spektrum an Softwarerisiken rund um den Datenaustausch systematisch abzusichern.

Verweise

1. JSON vs. XML (w3schools.com, Dezember 2016)

2. Der weltweite Erfolg von XML (W3C, Juli 2018)

3. W3C - Was ist ein XML-Schema? (W3C, Oktober 2009)

4. Das Internet: Eine historische Enzyklopädie. Chronologie, Band 3, p. 130 (ABC CLIO, 2005)

5. JSON-Schema (Juli 2008)

6. JSON-Schema-Validator (GitHub)

7. JsonSchema und SubClassing (Horne, März 2016)