Szczegółowe spojrzenie na JSON a XML, część 3: XML i przyszłość JSON

W części 2 tego artykułu przyjrzeliśmy się bliżej JSON jako wymianie danych i oceniliśmy jego mocne i słabe strony w przypadku prostych aplikacji w porównaniu do złożonych. JSON wyróżnia się jako najbardziej zwięzły, najbardziej kompaktowy format czytelny dla człowieka, ale jego podstawowa prostota może prowadzić do niezamierzonych implikacji w przypadku złożonych przypadków użycia. Dzięki JSON jako wymianie danych programiści są pozostawieni sami sobie w implementacji funkcji, których brakuje w samym JSON, co skutkuje połączonymi i niestandardowymi rozwiązaniami, które starają się wypełnić lukę. W przypadku rozwiązań korporacyjnych, które zdecydowanie zapewniają bezbłędne działanie, użycie JSON może skutkować niepożądanymi wzorcami, które mogą utrudnić jakość i stabilność kodu systemu oraz odporność na przyszłe niewiadome. Czy XML oferuje możliwości, które pomagają aplikacjom zmniejszyć to ryzyko? Czy te same funkcjonalności można osiągnąć za pomocą JSON? Bliższe przyjrzenie się XML jako wymianie danych ujawni jego mocne strony w zmniejszaniu ryzyka związanego z oprogramowaniem i zapewni programistom lepsze zrozumienie wzorców, które mogą pomóc w poprawie jakości ich aplikacji.

W części 3 tego artykułu:

1. Poznaj XML jako sposób wymiany danych i oceń jego mocne strony w obsłudze złożonych wymagań.
2. Omów przyszłość JSON i poznaj rozwiązania, które wnoszą mocne strony XML do JSON, aby umożliwić programistom tworzenie oprogramowania, które jest bardziej stabilne i bardziej odporne na błędy i przyszłe niewiadome.

XML jest łatwo oznaczony jako złożona i pełna alternatywa dla JSON. Witryna w3schools.com — popularne źródło informacji o standardach internetowych — zawiera zaledwie 58 słów na temat „Dlaczego JSON jest lepszy niż XML” ¹ . Tak uproszczona ocena JSON vs XML jest myląca, ponieważ XML zapewnia znacznie więcej niż tylko wymianę danych. W rzeczywistości XML nie został zaprojektowany tylko do wymiany danych, ale raczej jako język do określania niestandardowych języków znaczników dla dowolnej aplikacji. Dzięki ścisłej semantyce XML zdefiniował standard zapewniający integralność danych w dokumentach XML w dowolnym języku podrzędnym XML. Wielu programistów uważa, że ​​„XML zawiódł i został zastąpiony przez JSON”, ale nie może to być dalsze od prawdy. Pierwotnie XML miał być używany do rozwiązywania wszystkich problemów z interoperacyjnością danych i do dziś pozostaje „najczęściej używanym formatem na świecie do przedstawiania i wymiany informacji”. ²

JSON jest prosty, a XML jest potężny

W części 2 tego artykułu zbadaliśmy wymianę danych obejmującą umowy konsumenckie (CDC), ewolucję protokołu i weryfikację wiadomości. Mając JSON jako wymianę danych, nasz przykład — Bank Europejski — stanął przed wyzwaniem dostarczenia rozwiązania ograniczającego ryzyko w zakresie wymiany danych ze sprzedawcami detalicznymi. Bank poszukiwał wzorców oprogramowania, które skutkowały niskim sprzężeniem, wysoką enkapsulacją i wysoką odpornością na przyszłe niewiadome. Jednak z JSON jako wymianą danych bank został przedstawiony z wzorcami skutkującymi czymś przeciwnym: niską enkapsulacją, wysokim sprzężeniem i niższą odpornością na przyszłe niewiadome.

Wróćmy do przykładu Europejskiego Banku i zamieńmy JSON jako format wymiany danych na XML. Następujące komunikaty XML są równoważne komunikatom JSON dla każdego typu identyfikatora konta: SWIFT, IBAN i 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>

Pomimo natychmiastowej utraty wydajności zliczania surowych bajtów, XML uzasadnia swoją szczegółowość, obsługując szerszy zakres związany z wymianą danych. Dzięki kodowaniu danych za pomocą JSON byliśmy w stanie rozwiązać bezpośrednie wymagania wymiany danych, ale nic nie wspierało wielu wariantów wiadomości lub ich walidacji. Aby zająć się zakresem otaczającym umowy konsumenckie, programiści musieliby zaimplementować niestandardowy kod, który skutkowałby logicznym sprzężeniem między formatem wiadomości, jej treścią i funkcjonalną implementacją do jej przetwarzania. Alternatywnie, programista może zdecydować się na ułożenie puzzli z kolekcji bibliotek i frameworków, aby spełnić wyższe wymagania. Oba podejścia powodują powstanie cebuli warstw na górze wymiany danych, które są połączone bezpośrednio z aplikacją. Jednak kodując dane za pomocą XML, jesteśmy w stanie rozwiązać wiele ruchów wymagań bez sprzężenia.

Odpowiedniki komunikatów XML wykorzystują dwie szczególne cechy standardu XML: przestrzenie nazw i typy instancji. Atrybut xmlns="urn:bank:message" określa przestrzeń nazw wiadomości, a atrybut "xsi:type" określa jej typ wystąpienia, jako "swift" , "iban" lub "ach" . Te dwa atrybuty to standardy XML, które pozwalają procesorowi komunikatów zidentyfikować typ komunikatu, a także wyłuskać odwołania ze schematu definiującego reguły walidacji.

Schemat XML reprezentuje kluczowy wyróżnik między JSON i XML. Za pomocą schematu programista może zawrzeć normatywną definicję formatu komunikatu na nośniku niezależnym od aplikacji i zdefiniować ograniczenia wartości, zapewniając reguły walidacji wymuszone przez procesory XML. Przykładowy schemat dla Europejskiego Banku (z namespace: xmlns="urn:bank:message" ), wraz z deskryptorami typu i ograniczeniami wartości, to następujący dokument schematu XML (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>

Ten schemat XML jest logicznie równoważny funkcji isValid(message) z części 2. Na pierwszy rzut oka ten schemat XML jest znacznie bardziej szczegółowy niż isValid(message) . Jednak podstawowa różnica między nimi polega na tym, że isValid(message) jest połączona z aplikacją, a schemat XML nie. Schemat XML jest językiem do wyrażania ograniczeń dotyczących dokumentów XML i istnieje kilka różnych języków schematów w powszechnym użyciu, z których główne to: definicje typów dokumentów (DTD), Relax-NG, Schematron i definicje schematów XML W3C (XSD ). ³ Dla Europejskiego Banku schemat XML stanowi rozwiązanie o zmniejszonym ryzyku dla wymagań wyższych warstw bez sprzężenia.

Schemat XML powoduje mniejsze ryzyko oprogramowania. W języku XML reguły walidacji komunikatów są wyrażane w języku schematu, który jest odłączony od aplikacji, a zatem nie jest z nią połączony. Ponieważ schemat XML jest całkowicie oderwany od systemu, logiczne znaczenie formatu komunikatu i funkcjonalnej implementacji do jego przetwarzania są oddzielone. Schemat XML zapewnia Europejskiemu Bankowi hermetyzowaną warstwę, która jest wyłącznie odpowiedzialna za kontekst walidacji wiadomości, zmienność, wersjonowanie i inne.

Schemat XML reprezentuje normatywną definicję umowy konsumenckiej. Dla Europejskiego Banku zapewnia to podejście ograniczające ryzyko, które pozwala zredukować $\xi_0$ bliżej 0. Ponieważ schemat jest oddzielony od banku i sprzedawcy detalicznego, obie strony mogą go używać do walidacji i egzekwowania kontraktu.

Dlaczego schemat XML jest tak szczegółowy?

Specyfikacja schematu XML udostępnia programistom język do implementowania wzorców strukturalnych i logicznych używanych do definiowania i ograniczania wszystkich części składowych dowolnego dokumentu XML. Dzięki schematowi XML programiści są w stanie osadzić głębsze znaczenie w każdej strukturalnej i logicznej części dokumentu XML. Na przykład schemat XML pozwala na:

1. Definicja ograniczeń wyrażeń regularnych dla ciągów składowych,
2. Definiowanie zakresów i formatów liczb składowych,
3. Definicja wymaganych i opcjonalnych elementów składowych i atrybutów,
4. Definicja kluczowych i referencyjnych wymagań w dokumencie i wiele, wiele więcej.

Dzięki schematowi XML system może polegać na ogólnych walidatorach XML, aby potwierdzić ważność każdego komunikatu wejściowego, samoistnie zmniejszając „przestrzeń błędu” $\xi_0$ bliżej 0 i automatycznie izolując logikę biznesową od błędnych danych wejściowych.

Ryzyko przyszłego rozwoju

Systemy mogą wykorzystywać nieodłączne cechy specyfikacji XML w celu zmniejszenia ryzyka związanego z oprogramowaniem w przyszłości. Uzgadniając umowę normatywną w postaci schematu XML, systemy określają zasady i ograniczenia dla wszystkich obiektów i właściwości (elementów i atrybutów, w przypadku XML), które mają być wymieniane. Dzięki temu systemy są w stanie wykorzystać szerszy zakres specyfikacji XML, aby zająć się zmiennością komunikatów, wersjonowaniem protokołów i walidacją treści. Na przykład przestrzenie nazw XML dostarczają komunikatom XML informacji niezbędnych do:

1. Określ wersję wiadomości.
2. Odwołaj się do normatywnego schematu kontraktu.
3. Sprawdź poprawność dokumentu.

Dzięki szerokiej gamie funkcji i możliwości oferowanych przez schemat XML, większość złożonych wymagań związanych z wymianą danych można rozwiązać za pomocą samego XML. To właśnie miał na myśli dr Charles Goldfarb, kiedy powiedział: „[XML jest] świętym Graalem informatyki”. ⁴

Schemat XML pomaga aplikacjom być odpornym na błędy i podatnym na przyszłe zmiany.

XML jest powszechnie akceptowaną i dokładnie sprawdzoną specyfikacją z niezliczonymi bibliotekami dostępnymi dla wszystkich platform, które pomagają w przetwarzaniu i walidacji dokumentów XML. Z XML jako formatem wymiany danych, programista jest w stanie sprostać zarówno bieżącym wymaganiom, jak i tym, które dotyczą umów konsumenckich, zmienności komunikatów, wersjonowania protokołów i walidacji treści. XML umożliwia programiście zabezpieczenie się przed złożonymi wymaganiami i, co ważniejsze, przyszłymi niewiadomymi.

XML to znacznie więcej niż wymiana danych i może być używany do rozwiązywania problemów znacznie większych niż w przypadku JSON. Patrząc z tej perspektywy, zakres XML obejmuje większą część cebuli, przy czym kilka warstw cebuli jest zawartych w samym zakresie XML.

Czy przy wyborze najlepszego formatu wymiany danych dla aplikacji jest to tylko centrum cebuli, na której nam zależy, czy też cebula w całości?

Podstawowe różnice między JSON a XML

XML oferuje znacznie więcej niż wymianę danych i może być używany do rozwiązywania problemów znacznie większych niż w przypadku JSON. Zakres złożonych wymagań związanych z wymianą danych jest uwzględniony w XML, co pozwala systemom na wykorzystanie bibliotek i frameworków zgodnych ze standardem, odseparowanych od aplikacji.

XML to specyfikacja, która uwzględnia zakres złożonych wymagań w fazie projektowania i jest standardem zdefiniowanym przez W3C i obsługiwanym przez wszystkich odpowiednich dostawców oprogramowania i platformy językowe. Używając XML jako wymiany danych, aplikacje automatycznie czerpią korzyści z systematycznego zmniejszania ryzyka związanego z oprogramowaniem.

Przyszłość JSON

JSON niezaprzeczalnie tu zostanie. Ponieważ JavaScript jest obecnie najczęściej używaną platformą programistyczną, JSON stał się najbardziej znanym formatem wymiany danych. W przypadku małych projektów o niewielkiej złożoności JSON jest idealnym rozwiązaniem. Ale ponieważ staramy się tworzyć większe i lepsze aplikacje na przyszłość, ogólna złożoność naszego oprogramowania będzie wzrastać. Na przykładzie potężnych możliwości XML, kilka grup próbowało wymyślić podobne standardy dla JSON.

Fundamentalną wadą JSON jest brak ogólnego standardu normatywnego opisu logicznych składników jego dokumentów.

Schemat JSON

W 2009 roku grupa uruchomiła schemat JSON ⁵ , który jest słownikiem służącym do opisywania i sprawdzania poprawności dokumentów JSON. Schemat JSON używa semantyki JSON do definiowania zestawu reguł i ograniczeń dla składników dokumentów JSON, a kilka projektów na różnych platformach ma zaimplementowane biblioteki obsługujące specyfikację schematu JSON. Chociaż nie jest to jeszcze oficjalny standard, projekt schematu JSON zapewnia rozwiązanie zakresu wymagań, który jest podobny do specyfikacji schematu XML. Za pomocą słownika schematów JSON programiści mogą definiować reguły logiczne i strukturalne oraz ograniczenia dokumentów JSON. Schemat może następnie służyć do wspomagania przetwarzania i sprawdzania poprawności dokumentów JSON z bibliotekami, które są oddzielone od aplikacji, zmniejszając w ten sposób potrzebę mieszania niehermetyzowanego kodu w aplikacji. Dzięki schematowi JSON programista może wybrać JSON jako format wymiany danych i adresować, w sposób zmniejszający ryzyko, złożone wymagania, których nie można było wcześniej adresować za pomocą samego JSON.

Projekt schematu JSON jest dziełem społeczności i po dziesięciu latach poprawek jest dominującą specyfikacją schematów JSON. Choć nie jest to jeszcze standard, popularność projektu schematu JSON wskazuje na zainteresowanie takim rozwiązaniem. Koncepcyjnie specyfikacja schematu JSON przypomina schemat XML, ale porównanie tych dwóch ujawnia różnice między ich modelami, możliwościami i semantyką. Na przykład, chociaż język definiuje szeroki zakres właściwości, aby ograniczyć granice typów wartości JSON, jego liczne atrybuty pozwalają na wyrażanie sprzecznych definicji schematów.

Na przykład poniższy fragment definiuje typ "object" , który zawiera trzy właściwości: "number" , "street_name" i "street_type" .

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

Definicja typu "object" akceptuje dodatkowe ograniczenia, z których jedno to "minProperties" . Modyfikując powyższą definicję typu "object" za pomocą "minProperties": "4" , definicja staje się bezsensowna, ponieważ tylko trzy właściwości są jawnie zdefiniowane dla obiektu.

Schemat JSON ma dość dużą i szeroką liczbę właściwości ograniczających, z których wiele jest niezbędnych do skutecznego ograniczania dokumentów JSON, a wiele z nich nakłada się na siebie. Z właściwościami ograniczeń, które nakładają się na siebie, słownik schematu JSON przedstawia dwie rodziny wyzwań:

1. Wymaga od programistów większej nauki ze względu na szerokie słownictwo i nietypowe lub niekonwencjonalne niuanse w jego semantyce.
2. Bibliotekom walidacyjnym trudniej jest zaimplementować, co prowadzi do rozwiązań, które w różny sposób implementują szare obszary, co skutkuje niespójnymi implementacjami.

Sam język schematów XML nie jest całkowicie wolny od zezwalania na wyrażanie sprzecznych z sobą definicji, ale jest ich znacznie mniej i są one ograniczone. W rzeczywistości specyfikacja schematu XML została opracowana z dużą dbałością o łatwość użycia zarówno dla programistów, jak i bibliotek implementujących specyfikację. Ponadto projekt schematu JSON definiuje tylko specyfikację języka schematu, ale istnieje wiele projektów społeczności, które implementują tę specyfikację.

Walidator schematu JSON ⁶ to popularny projekt, który implementuje walidator schematu JSON dla platformy Java. Integrując tę ​​bibliotekę z aplikacją Java, aplikacja jest w stanie zapewnić zgodność wszystkich wymienianych dokumentów JSON. Inne implementacje specyfikacji schematu JSON są dostępne dla różnych platform.

W przypadku Europejskiego Banku użyjmy schematu JSON, aby zaimplementować schemat komunikatów JSON z identyfikatorami kont.

 { "$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"] } } } }

Ten schemat JSON definiuje 3 typy obiektów: "swift" , "iban" i "ach" . Określa wzorce wyrażeń regularnych, aby potwierdzić, że informacje o koncie nie są nieprawidłowe, i deklaruje "type" i "code" jako wymagane właściwości dla każdego typu, oprócz "routing" jako właściwości wymaganej dla typu "ach" . Za pomocą tego schematu JSON Europejski Bank może zweryfikować swoje dane wejściowe JSON, aby potwierdzić, że treść wiadomości jest poprawna dla każdej interakcji.

Schemat JSON wprowadza wiele możliwości XML do JSON, ale nadal trwają prace nad tym. Chociaż jest to świetne rozwiązanie, które można wykorzystać do zabezpieczenia przed ryzykiem związanym z oprogramowaniem, specyfikacja schematu JSON nie jest idealna. Ze względu na nieformalną ewolucję swojego języka, język ewoluował w kierunku, w którym pomija się prawdopodobnie ważne cechy i zawiera strukturalne i logiczne wzorce ekspresji, które są mylące i niekonwencjonalne. Na przykład język schematu nie ma możliwości definiowania typów abstrakcyjnych, co może prowadzić programistów do wdrażania zawiłych obejścia, które skutkują własnym ryzykiem związanym z oprogramowaniem. ⁷

Projekt schematu JSON wniósł nieoceniony wkład w koncepcje języka schematów dla JSON. Pomimo braków w jasności jego semantyki, język schematów JSON jest wszechstronnym rozwiązaniem, które wprowadza wiele możliwości XML do JSON.

Aby bliżej przyjrzeć się specyfikacji schematu JSON, zobacz Understanding JSON Schema.

JSONx

W 2014 roku inna grupa rozpoczęła projekt JSONx, który bezpośrednio wykorzystuje XML, aby zapewnić równie potężne rozwiązanie dla JSON. Projekt JSONx został stworzony specjalnie dla przedsiębiorstw i definiuje język definicji schematu JSON (JSD), który jest modelowany blisko specyfikacji schematu XML. Używając schematu XML jako modelu, JSD definiuje wzorce strukturalne i logiczne, które są bardzo podobne do języka definicji schematu XML.

Dla przykładu Europejskiego Banku użyjmy języka JSD do zaimplementowania schematu komunikatów JSON z identyfikatorami kont.

 { "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 } } } }

Na pierwszy rzut oka schemat JSD jest podobny w wyrażeniu do schematu JSON. Jedną różnicą jest jednak zwięzła semantyka JSD w porównaniu ze schematem JSON. Specyficzne dla tego przykładu JSD umieszcza właściwość "use": "required" w określonej definicji, podczas gdy schemat JSON kojarzy tę właściwość z obiektem nadrzędnym, wymagając, aby nazwa wartości była zgodna z nazwą definicji właściwości. Ograniczenie "use": "required" jest określone tylko we właściwości "code" obiektu "swift" i jest pomijane w innych, ponieważ "use": "required" jest wartością domyślną. Język JSD został zaprojektowany z uwzględnieniem wszystkich takich niuansów i oferuje przejrzyste i intuicyjne rozwiązanie do wyrażania schematów JSON.

Od samego początku wyróżniająca właściwość projektu JSONx jest jego głównym celem, aby zapewnić programistom przejrzystość i użyteczność. Aby to osiągnąć, potężną cechą JSD jest jego konwertowalność do JSDx — język JSD można wyrazić w plikach JSON, a także w plikach XML. Oba formularze można tłumaczyć jeden do jednego i zapewniają programistom możliwość korzystania z zaawansowanych narzędzi do edycji XML, aby pomóc w tworzeniu dokumentów JSD, które mają być sprawdzane na żywo i bez błędów.

Powyższy schemat JSD można wyrazić w postaci JSDx:

 <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>

Forma JSDx JSD jest bardzo wydajna, ponieważ zapewnia przejrzystą, samosprawdzającą i zmniejszającą ryzyko specyfikację definiowania schematów JSON.

Język JSD jest przeznaczony do rozwiązywania problemów związanych z wewnętrznie sprzecznymi definicjami i opiera się na standardowych wzorcach do wyrażania ograniczeń. Zaprojektowane w sposób zbliżony do języka definicji schematu XML (XSD), deklaracje typu JSD i definicje ograniczeń są bardzo podobne do równoważnych struktur w XML. Specyfikacja JSD(x) zapewnia kompletne rozwiązanie do definiowania ograniczeń strukturalnych i logicznych i jest samoopisująca — dostarcza normatywną definicję języka JSD(x) wyrażoną w samym języku JSD(x). Aby bliżej przyjrzeć się specyfikacji JSD(x), zapoznaj się z JSON Schema Definition Language.

Oprócz języka JSD(x) projekt JSONx udostępnia referencyjne implementacje procesorów i walidatorów JSD(x), a także interfejs API do wiązania klas i generator kodu dla platformy Java. Za pomocą interfejsu API powiązania i generatora programista może użyć schematu JSD(x) do automatycznego generowania klas dla definicji obiektów w żądanym schemacie, których można użyć do analizowania i porządkowania dokumentów JSON zgodnych ze schematem. Wygenerowane klasy zapewniają ściśle określone powiązanie między schematem a platformą Java, reprezentujące użycie, ograniczenia i relacje określone w schemacie. Dzięki silnie wpisanym powiązaniom ze schematem aplikacja dodatkowo zmniejsza ryzyko oprogramowania związane z przyszłymi modyfikacjami, które mogą spowodować niezgodności.

Wykorzystując kompilator Javy, silnie typizowane powiązania wskazują niezgodności z błędami czasu kompilacji, skutecznie zmniejszając ryzyko błędów związanych z przetwarzaniem wiadomości bliskie zeru. Ten wzorzec inżynierski umożliwia programistom szybkie i pewne rozwiązywanie zmian i rozwiązywanie niezgodności, bez konieczności polegania na środowisku wykonawczym w celu znalezienia błędów lub przypadków niepowodzeń — a zwłaszcza bez konieczności polegania na użytkownikach, którzy sami natkną się na błędy. Wiązanie API jest implementowane z adnotacjami Java, które umożliwiają powiązanie dowolnej klasy ze schematem JSD(x) z silnymi typami, ale w lekki sposób. Możliwości JSONx związane z silnymi typami powiązania i generowania kodu obsługują pełny zakres specyfikacji JSD(x), zaprojektowanej specjalnie w celu spełnienia wysokich standardów dla rozwiązań dla przedsiębiorstw.

Framework JSONx został stworzony dla rozwiązań korporacyjnych i oferuje wysoki standard jakości i użyteczności dla złożonych systemów, a także łatwość użycia i walidację błędów w czasie edycji dla programistów.

Mechanizm wiązania, procesor i walidator JSD(x) zgłaszają 87% pokrycia testów, co pozwala programistom Java na bezpieczną integrację struktury w celu wiązania schematów JSD(x) z ich aplikacjami Java oraz kodowania, dekodowania i walidacji dokumentów JSON. Aby bliżej przyjrzeć się strukturze JSONx for Java, zapoznaj się z JSONx Framework for Java.

Wniosek

Przy głębszym przyjrzeniu się historii trendów internetowych i oprogramowania w ostatnich latach, możemy dostrzec ścisły związek między proliferacją JavaScript a popularnością JSON. Wiele artykułów i postów na blogach oferuje ograniczoną perspektywę przy porównywaniu JSON i XML, co prowadzi czytelników do dyskontowania XML jako przestarzałego i pozostawia wielu nieświadomych potężnych możliwości, które mogą pomóc im ulepszyć architekturę oprogramowania, odporność oprogramowania na zmiany oraz ogólną jakość i stabilność oprogramowania jako całości. Dzięki głębszej ocenie mocnych i słabych stron każdego standardu programiści mogą być upoważnieni do podejmowania lepszych decyzji dotyczących swoich projektów.

Podobnie jak „katastrofa rozbieżności” z HTML, która doprowadziła do wynalezienia XML, podobny efekt jest realizowany w złożonych bazach kodu, które opierają się na JSON do wymiany danych. Specyfikacja JSON nie zawiera bezpośrednich funkcji związanych z wymianą danych, co może prowadzić do fragmentacji logiki w wyższych warstwach aplikacji. Jednak dzięki XML programiści są w stanie zepchnąć złożoność związaną z wymianą danych na niższe warstwy aplikacji, co umożliwia wyłapywanie błędów na wcześniejszym etapie cyklu życia aplikacji. Zwłaszcza w przypadku języków skompilowanych, w połączeniu z platformą powiązań, architektury, które opierają się na powiązaniu XML, mogą zmniejszyć prawdopodobieństwo wystąpienia błędu związanego z danymi do zera. Dla przedsiębiorstwa to właśnie te potężne możliwości systematycznego zmniejszania ryzyka związanego z oprogramowaniem sprawiają, że XML jest „świętym Graalem informatyki”.

JSON nie zniknie, a kilka projektów nabiera rozpędu, oferując potężne możliwości XML do JSON. Projekt schematu JSON oferuje opracowaną przez społeczność specyfikację schematu, która rozwinęła się organicznie w celu obsługi szerokiej gamy atrybutów i wzorców deklaratywnych do opisywania i ograniczania dokumentów JSON. Projekt JSONx dostarcza język schematów klasy korporacyjnej, który jest bardzo podobny do języka definicji schematu XML i oferuje zarówno formaty JSON, jak i XML do specyfikacji dokumentów schematów JSON. Dzięki tym specyfikacjom i strukturom programiści są w stanie zmniejszyć ryzyko związane z oprogramowaniem związane z wymaganiami wyższych warstw związanych z wymianą danych, takimi jak umowy konsumenckie, wersjonowanie protokołów, weryfikacja treści i inne.

Zaawansowane funkcje XML zostały zaprojektowane w celu ograniczenia ryzyka oprogramowania związanego z językami znaczników. Przypadki użycia z JSON nie różnią się od siebie, a język schematów jest sprawdzonym i sprawdzonym rozwiązaniem do systematycznego zabezpieczania szerokiego zakresu ryzyka związanego z oprogramowaniem związanym z wymianą danych.

Bibliografia

1. JSON a XML (w3schools.com, grudzień 2016)

2. Światowy sukces, jakim jest XML (W3C, lipiec 2018)

3. W3C – Co to jest schemat XML? (W3C, październik 2009)

4. Internet: encyklopedia historyczna. Chronologia, tom 3, s. 130 (ABC-CLIO, 2005)

5. Schemat JSON (lipiec 2008)

6. Walidator schematu JSON (GitHub)

7. JsonSchema i podklasy (Horne, marzec 2016)