Pandangan Mendalam tentang JSON vs. XML, Bagian 3: XML dan Masa Depan JSON

Di Bagian 2 artikel ini, kami melihat lebih dekat JSON sebagai pertukaran data dan mengevaluasi kekuatan dan kelemahannya untuk aplikasi sederhana versus kompleks. JSON menonjol sebagai format yang paling ringkas dan paling ringkas yang dapat dibaca manusia, tetapi kesederhanaan dasarnya dapat menyebabkan implikasi yang tidak diinginkan saat digunakan untuk kasus penggunaan yang kompleks. Dengan JSON sebagai pertukaran data, pengembang dibiarkan sendiri untuk mengimplementasikan fungsionalitas yang hilang dari JSON itu sendiri, menghasilkan solusi gabungan dan non-standar yang mencoba memenuhi celah tersebut. Untuk solusi perusahaan yang bersikeras dalam menegaskan operasi bebas kesalahan, penggunaan JSON dapat menghasilkan pola yang tidak diinginkan yang dapat menghambat kualitas kode sistem, stabilitas, dan ketahanan terhadap hal-hal yang tidak diketahui di masa depan. Apakah XML menawarkan kemampuan untuk membantu aplikasi mengurangi risiko ini? Bisakah fungsi yang sama dicapai dengan JSON? Melihat lebih dekat XML sebagai pertukaran data akan mengungkapkan kekuatannya dalam mengurangi risiko perangkat lunak dan memberikan pemahaman yang lebih baik kepada pengembang tentang pola yang dapat membantu meningkatkan kualitas aplikasi mereka.

Di Bagian 3 artikel ini, kami akan:

1. Jelajahi XML sebagai pertukaran data dan evaluasi kekuatannya dalam mendukung persyaratan yang kompleks.
2. Diskusikan masa depan JSON dan jelajahi solusi yang menghadirkan kekuatan XML ke JSON untuk memungkinkan pengembang membangun perangkat lunak yang lebih stabil dan lebih tahan terhadap bug dan hal yang tidak diketahui di masa depan.

XML siap diberi label sebagai alternatif yang kompleks dan bertele-tele untuk JSON. Situs web w3schools.com—referensi populer untuk standar web—menawarkan hanya 58 kata tentang topik “Mengapa JSON lebih baik daripada XML” ¹ . Evaluasi sederhana dari JSON vs XML menyesatkan, karena XML menyediakan lebih dari sekedar pertukaran data. Faktanya, XML tidak dirancang hanya untuk pertukaran data, melainkan sebagai bahasa untuk menentukan bahasa markup khusus untuk aplikasi apa pun. Dengan semantiknya yang ketat, XML mendefinisikan standar untuk menegaskan integritas data dokumen XML, dari sub-bahasa XML apa pun. Banyak pengembang percaya bahwa "XML gagal dan diganti dengan JSON," tetapi ini tidak bisa jauh dari kebenaran. Awalnya, XML dibayangkan untuk digunakan untuk semua masalah interoperabilitas data, dan sampai hari ini tetap sebagai "format yang paling banyak digunakan di dunia untuk mewakili dan bertukar informasi." ²

JSON Sederhana, dan XML Kuat

Di Bagian 2 artikel ini, kami menjelajahi pertukaran data yang melibatkan kontrak berbasis konsumen (CDC), evolusi protokol, dan validasi pesan. Dengan JSON sebagai pertukaran data, contoh kami—European Bank—ditantang untuk memberikan solusi mitigasi risiko untuk pertukaran data dengan pengecer. Bank menginginkan pola perangkat lunak yang menghasilkan kopling rendah, enkapsulasi tinggi, dan ketahanan tinggi terhadap hal-hal yang tidak diketahui di masa depan. Namun, dengan JSON sebagai pertukaran data, bank disajikan dengan pola yang menghasilkan kebalikannya: enkapsulasi rendah, kopling tinggi, dan ketahanan yang lebih rendah terhadap hal-hal yang tidak diketahui di masa depan.

Mari kita lihat kembali contoh Bank Eropa dan ganti JSON sebagai format pertukaran data dengan XML. Pesan XML berikut ini setara dengan pesan JSON untuk setiap jenis pengenal akun: SWIFT, IBAN, dan 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>

Meskipun kerugian langsung dalam efisiensi jumlah byte mentah, XML membenarkan verbositasnya dengan mendukung cakupan yang lebih luas seputar pertukaran data. Dengan menyandikan data dengan JSON, kami dapat menyelesaikan persyaratan langsung dari pertukaran data tetapi tidak mendukung beberapa varian pesan atau validasinya. Untuk mengatasi cakupan seputar kontrak berbasis konsumen, pengembang perlu menerapkan kode khusus yang akan menghasilkan penggabungan logis antara format pesan, kontennya, dan implementasi fungsional untuk pemrosesannya. Atau, pengembang dapat memilih untuk mengumpulkan teka-teki dari koleksi perpustakaan dan kerangka kerja untuk memenuhi persyaratan yang lebih tinggi. Kedua pendekatan menghasilkan bawang lapisan di atas pertukaran data yang digabungkan langsung ke aplikasi. Namun, dengan mengkodekan data dengan XML, kami dapat menyelesaikan banyak persyaratan tanpa kopling.

Setara pesan XML menggunakan dua fitur khusus dari standar XML: ruang nama dan tipe instans. Atribut xmlns="urn:bank:message" menentukan namespace pesan, dan atribut "xsi:type" menentukan jenis instansnya, sebagai "swift" , "iban" , atau "ach" . Kedua atribut ini adalah standar XML yang memungkinkan pemroses pesan untuk mengidentifikasi jenis pesan serta melakukan dereferensi skema yang mendefinisikan aturan validasi.

Skema XML mewakili pembeda utama antara JSON dan XML. Dengan skema, pengembang dapat merangkum definisi normatif dari format pesan dalam media yang terpisah dari aplikasi dan menentukan batasan nilai yang menyediakan aturan validasi yang ditegakkan oleh prosesor XML. Contoh skema untuk Bank Eropa (dengan namespace: xmlns="urn:bank:message" ), lengkap dengan deskriptor tipe dan batasan nilai, adalah dokumen skema 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>

Skema XML ini secara logis setara dengan fungsi isValid(message) dari Bagian 2. Pada tampilan pertama, skema XML ini jauh lebih verbose daripada isValid(message) . Perbedaan mendasar antara keduanya, bagaimanapun, adalah bahwa isValid(message) digabungkan ke aplikasi, dan skema XML tidak. Skema XML adalah bahasa untuk mengekspresikan batasan tentang dokumen XML dan ada beberapa bahasa skema berbeda yang digunakan secara luas, yang utama adalah: definisi tipe dokumen (DTD), Relax-NG, Schematron, dan definisi skema XML W3C (XSD). ). ³ Untuk Bank Eropa, skema XML menyediakan solusi pengurangan risiko untuk persyaratan lapisan yang lebih tinggi tanpa kopling.

Skema XML menghasilkan risiko perangkat lunak yang lebih rendah. Dengan XML, aturan untuk validasi pesan diekspresikan dalam bahasa skema yang terputus dari, dan dengan demikian tidak digabungkan ke, aplikasi. Karena skema XML sepenuhnya terlepas dari sistem, makna logis dari format pesan dan implementasi fungsional untuk pemrosesannya dipisahkan. Skema XML memberi Bank Eropa lapisan terenkapsulasi yang bertanggung jawab penuh atas konteks validasi pesan, variabilitas, pembuatan versi, dan banyak lagi.

Skema XML mewakili definisi normatif dari kontrak yang digerakkan oleh konsumen. Untuk Bank Eropa, ini memberikan pendekatan mitigasi risiko untuk mengurangi $\xi_0$ mendekati 0. Karena skema dipisahkan dari bank dan pengecer, kedua belah pihak dapat menggunakannya untuk memvalidasi dan menegakkan kontrak.

Mengapa Skema XML Begitu Verbose?

Spesifikasi skema XML menyediakan bahasa bagi pengembang untuk menerapkan pola struktural dan logis yang digunakan untuk mendefinisikan dan membatasi semua bagian konstituen dari dokumen XML apa pun. Dengan skema XML, pengembang dapat menanamkan makna yang lebih dalam ke setiap bagian struktural dan logis dari dokumen XML. Misalnya, skema XML memungkinkan untuk:

1. Definisi batasan ekspresi reguler untuk string konstituen,
2. Definisi rentang dan format untuk bilangan konstituen,
3. Definisi elemen dan atribut konstituen yang diperlukan dan opsional,
4. Definisi persyaratan kunci dan referensi dalam dokumen, dan banyak lagi.

Dengan skema XML, sistem dapat mengandalkan validator XML generik untuk menegaskan validitas setiap pesan input, secara intrinsik mengurangi "ruang kesalahan" $\xi_0$ mendekati 0 dan secara otomatis mengisolasi logika bisnis dari input yang salah.

Risiko Perkembangan Masa Depan

Sistem dapat memanfaatkan fitur bawaan dari spesifikasi XML untuk mengurangi risiko pengembangan perangkat lunak di masa mendatang. Dengan menyetujui kontrak normatif dalam bentuk skema XML, sistem menentukan aturan dan batasan untuk semua objek dan properti (elemen dan atribut, untuk XML) yang akan dipertukarkan. Sistem selanjutnya dapat memanfaatkan cakupan spesifikasi XML yang lebih luas untuk mengatasi variabilitas pesan, versi protokol, dan validasi konten. Misalnya, ruang nama XML menyediakan pesan XML dengan informasi yang diperlukan untuk:

1. Identifikasi versi pesan.
2. Dereference skema kontrak normatif.
3. Memvalidasi kebenaran dokumen.

Dengan luasnya fitur dan kemampuan yang ditawarkan oleh skema XML, sebagian besar persyaratan kompleks seputar pertukaran data dapat diselesaikan dengan XML itu sendiri. Inilah yang dimaksud oleh Dr. Charles Goldfarb ketika dia mengatakan “[XML adalah] cawan suci komputasi.” ⁴

Skema XML membantu aplikasi agar tahan terhadap kesalahan dan fleksibel terhadap perubahan di masa mendatang.

XML adalah spesifikasi yang diterima secara luas dan diperiksa secara menyeluruh dengan perpustakaan yang tak terhitung jumlahnya tersedia untuk semua platform untuk membantu dalam pemrosesan dan validasi dokumen XML. Dengan XML sebagai format pertukaran data, pengembang dapat menyelesaikan persyaratan langsung serta persyaratan yang terkait dengan kontrak berbasis konsumen, variabilitas pesan, versi protokol, dan validasi konten. XML memungkinkan pengembang untuk melindungi risiko persyaratan yang kompleks dan, yang lebih penting, dari hal-hal yang tidak diketahui di masa depan.

XML lebih dari sekadar pertukaran data dan dapat digunakan untuk mengatasi masalah yang jauh lebih besar daripada dengan JSON. Jika dilihat dari perspektif ini, ruang lingkup XML mencakup sebagian besar bawang, di mana beberapa lapisan bawang terkandung dalam ruang lingkup XML itu sendiri.

Saat memilih format pertukaran data terbaik untuk suatu aplikasi, apakah hanya bagian tengah bawang yang kami pedulikan, atau bawang merah secara keseluruhan?

Perbedaan Mendasar Antara JSON dan XML

XML menawarkan lebih dari sekadar pertukaran data dan dapat digunakan untuk mengatasi masalah yang jauh lebih besar daripada dengan JSON. Cakupan persyaratan kompleks seputar pertukaran data diakomodasi oleh XML, memungkinkan sistem untuk memanfaatkan perpustakaan dan kerangka kerja yang sesuai dengan standar, dipisahkan dari aplikasi.

XML adalah spesifikasi yang membahas ruang lingkup persyaratan kompleks berdasarkan desain dan merupakan standar yang ditentukan oleh W3C dan didukung oleh semua vendor perangkat lunak dan platform bahasa yang relevan. Dengan menggunakan XML sebagai pertukaran data, aplikasi secara otomatis mendapat keuntungan dari pengurangan risiko perangkat lunak secara sistematis.

Masa Depan JSON

JSON tidak dapat disangkal di sini untuk tinggal. Dengan JavaScript sebagai platform pengembangan yang paling banyak digunakan saat ini, JSON telah menjadi format pertukaran data yang paling menonjol. Untuk proyek kecil dengan kompleksitas rendah, JSON sangat cocok. Namun saat kami berusaha untuk membuat aplikasi yang lebih besar dan lebih baik untuk masa depan, kompleksitas umum perangkat lunak kami ditakdirkan untuk meningkat. Dengan kemampuan kuat XML sebagai contoh, beberapa kelompok telah berusaha untuk menciptakan standar serupa untuk JSON.

Kekurangan mendasar dari JSON adalah kurangnya menyediakan standar umum untuk deskripsi normatif dari konstituen logis dari dokumennya.

Skema JSON

Pada tahun 2009, sebuah grup memulai skema JSON ⁵ , yang merupakan kosakata untuk membubuhi keterangan dan memvalidasi dokumen JSON. Skema JSON menggunakan semantik JSON untuk mendefinisikan seperangkat aturan dan batasan untuk konstituen dokumen JSON, dan beberapa proyek di berbagai platform telah mengimplementasikan pustaka yang mendukung spesifikasi skema JSON. Meskipun belum menjadi standar resmi, proyek skema JSON menyediakan solusi untuk cakupan persyaratan yang mirip dengan spesifikasi skema XML. Dengan kosakata skema JSON, pengembang dapat menentukan aturan logis dan struktural serta batasan dokumen JSON. Skema kemudian dapat digunakan untuk membantu dalam pemrosesan dan validasi dokumen JSON dengan pustaka yang dipisahkan dari aplikasi, sehingga mengurangi kebutuhan kode yang tidak dienkapsulasi untuk digabungkan dalam aplikasi. Dengan skema JSON, pengembang dapat memilih JSON sebagai format pertukaran data dan alamatnya, dengan cara yang mengurangi risiko, persyaratan kompleks yang sebelumnya tidak dapat ditangani dengan JSON saja.

Proyek skema JSON adalah upaya komunitas, dan setelah satu dekade revisi, berdiri sebagai spesifikasi yang berlaku untuk skema JSON. Meskipun belum menjadi standar, popularitas proyek skema JSON menunjukkan tingkat minat untuk solusi semacam itu. Secara konseptual, spesifikasi skema JSON menyerupai skema XML, tetapi perbandingan keduanya mengungkapkan perbedaan antara model, kemampuan, dan semantiknya. Misalnya, meskipun bahasa mendefinisikan berbagai properti untuk membatasi batas tipe nilai JSON, banyak atributnya memungkinkan ekspresi definisi skema yang saling bertentangan.

Misalnya, kutipan berikut mendefinisikan tipe "object" yang berisi tiga properti: "number" , "street_name" , dan "street_type" .

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

Definisi tipe "object" menerima batasan tambahan, salah satunya adalah "minProperties" . Dengan memodifikasi definisi tipe "object" di atas dengan "minProperties": "4" , definisi menjadi tidak masuk akal, karena hanya tiga properti yang didefinisikan secara eksplisit untuk objek.

Skema JSON memiliki jumlah properti kendala yang cukup besar dan luas, banyak di antaranya penting untuk membatasi dokumen JSON secara efektif, dan banyak di antaranya tumpang tindih satu sama lain. Dengan properti kendala yang tumpang tindih dalam arti, kosakata skema JSON menghadirkan dua keluarga tantangan:

1. Ini membutuhkan kurva belajar yang lebih tinggi dari pengembang, karena kosakata yang luas dan nuansa yang tidak biasa atau tidak konvensional dalam semantiknya.
2. Lebih sulit untuk mengimplementasikan library validasi, yang mengarah ke solusi yang mengimplementasikan area abu-abu secara berbeda, yang menghasilkan implementasi yang tidak konsisten.

Bahasa skema XML itu sendiri tidak sepenuhnya bebas dari ekspresi definisi yang saling bertentangan, tetapi jauh lebih sedikit dan terbatas. Faktanya, spesifikasi skema XML dikembangkan dengan memperhatikan baik kemudahan penggunaan untuk pengembang maupun untuk perpustakaan yang mengimplementasikan spesifikasi. Selanjutnya, proyek skema JSON hanya mendefinisikan spesifikasi bahasa skema, tetapi ada banyak proyek komunitas yang mengimplementasikan spesifikasi ini.

Validator skema JSON ⁶ adalah proyek populer yang mengimplementasikan validator skema JSON untuk platform Java. Dengan mengintegrasikan perpustakaan ini dalam aplikasi Java, aplikasi dapat menegaskan kesesuaian semua dokumen JSON yang dipertukarkan. Implementasi lain dari spesifikasi skema JSON tersedia untuk berbagai platform.

Untuk Bank Eropa, mari gunakan skema JSON untuk menerapkan skema pesan JSON dengan pengenal akun.

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

Skema JSON ini mendefinisikan 3 jenis objek: "swift" , "iban" , dan "ach" . Ini menentukan pola ekspresi reguler untuk menegaskan informasi akun tidak valid, dan menyatakan "type" dan "code" sebagai properti yang diperlukan untuk setiap jenis, selain "routing" sebagai properti yang diperlukan untuk jenis "ach" . Dengan skema JSON ini, Bank Eropa dapat memvalidasi input JSON-nya untuk menegaskan bahwa konten pesan sudah benar untuk setiap interaksi.

Skema JSON membawa banyak kemampuan XML ke JSON, tetapi masih dalam proses. Meskipun ini adalah solusi hebat yang dapat digunakan untuk melindungi risiko perangkat lunak, spesifikasi skema JSON tidak sempurna. Karena evolusi informal bahasanya, bahasa telah berevolusi ke arah yang menghilangkan fitur-fitur penting dan mengandung pola ekspresi struktural dan logis yang membingungkan dan tidak konvensional. Misalnya, bahasa skema tidak memiliki kemampuan untuk mendefinisikan tipe abstrak, yang dapat mengarahkan pengembang untuk menerapkan solusi yang berbelit-belit yang menghasilkan risiko perangkat lunak terkaitnya sendiri. ⁷

Proyek skema JSON telah membawa kekayaan kontribusi yang tak ternilai bagi konsep di balik bahasa skema untuk JSON. Terlepas dari kekurangan dalam kejelasan semantiknya, bahasa skema JSON adalah solusi serbaguna yang membawa banyak kemampuan XML ke JSON.

Untuk melihat lebih dekat spesifikasi skema JSON, lihat Memahami Skema JSON.

JSONx

Pada tahun 2014, grup lain memulai proyek JSONx, yang secara langsung memanfaatkan XML untuk memberikan solusi yang sama kuatnya untuk JSON. Proyek JSONx dibuat khusus untuk perusahaan, dan mendefinisikan bahasa definisi skema JSON (JSD), yang dimodelkan secara dekat dengan spesifikasi skema XML. Menggunakan skema XML sebagai modelnya, JSD mendefinisikan pola struktural dan logis yang memiliki kemiripan yang dekat dengan bahasa definisi skema XML.

Untuk contoh Bank Eropa, mari gunakan bahasa JSD untuk mengimplementasikan skema pesan JSON dengan pengenal akun.

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

Sekilas, skema JSD mirip dengan ekspresi skema JSON. Satu perbedaan, bagaimanapun, adalah semantik singkat dari JSD dibandingkan dengan skema JSON. Khusus untuk contoh ini, JSD menempatkan properti "use": "required" ke dalam definisi yang ditentukan, sedangkan skema JSON mengaitkan properti ini dengan objek induk, yang memerlukan nama nilai agar sesuai dengan nama definisi properti. Batasan "use": "required" hanya ditentukan pada properti "code" dari objek "swift" dan dihilangkan dari yang lain karena "use": "required" adalah nilai default. Bahasa JSD dirancang dengan mempertimbangkan semua nuansa tersebut dan menawarkan solusi yang bersih dan intuitif untuk ekspresi skema JSON.

Sejak awal, properti yang membedakan proyek JSONx adalah tujuan utamanya untuk memberikan kejelasan dan utilitas kepada pengembang. Untuk mencapai hal ini, fitur canggih JSD adalah konvertibilitasnya ke JSDx—bahasa JSD dapat diekspresikan dalam file JSON serta file XML. Kedua formulir dapat diterjemahkan satu-ke-satu dan memberi pengembang kemampuan untuk menggunakan alat pengeditan XML tingkat lanjut untuk membantu pembuatan dokumen JSD agar divalidasi langsung dan bebas kesalahan.

Skema JSD dari atas dapat dinyatakan dalam bentuk JSDx berikut:

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

Bentuk JSDx dari JSD sangat kuat karena menyediakan spesifikasi yang jelas, memvalidasi sendiri, dan mengurangi risiko untuk mendefinisikan skema JSON.

Bahasa JSD dirancang untuk mengatasi masalah definisi yang saling bertentangan, dan bergantung pada pola standar untuk ekspresi kendala. Dirancang sangat mirip dengan bahasa definisi skema XML (XSD), deklarasi tipe JSD dan definisi batasan memiliki kemiripan yang dekat dengan struktur yang setara dalam XML. Spesifikasi JSD(x) memberikan solusi lengkap untuk definisi kendala struktural dan logis, dan menggambarkan dirinya sendiri—memberikan definisi normatif dari bahasa JSD(x) yang diekspresikan dalam bahasa JSD(x) itu sendiri. Untuk melihat lebih dekat spesifikasi JSD(x), lihat Bahasa Definisi Skema JSON.

Selain bahasa JSD(x), proyek JSONx menyediakan implementasi referensi dari prosesor dan validator JSD(x) serta API pengikatan kelas dan pembuat kode untuk platform Java. Dengan API dan generator yang mengikat, pengembang dapat menggunakan skema JSD(x) untuk membuat kelas secara otomatis untuk definisi objek dalam skema yang diinginkan, yang dapat digunakan untuk mengurai dan menyusun dokumen JSON yang sesuai dengan skema. Kelas yang dihasilkan menyediakan pengikatan yang diketik dengan kuat antara skema dan platform Java, yang mewakili penggunaan, batasan, dan hubungan yang ditentukan dalam skema. Dengan ikatan yang diketik dengan kuat ke skema, aplikasi semakin mengurangi risiko perangkat lunak yang terkait dengan modifikasi di masa mendatang yang dapat mengakibatkan ketidakcocokan.

Dengan memanfaatkan kompiler Java, binding yang diketik dengan kuat menunjukkan ketidaksesuaian dengan kesalahan waktu kompilasi, secara efektif mengurangi risiko bug terkait pemrosesan pesan mendekati nol. Pola rekayasa ini memungkinkan pengembang untuk menerapkan perubahan dan menyelesaikan ketidaksesuaian dengan cepat dan percaya diri, tidak harus bergantung pada waktu proses untuk menemukan bug atau kasus kegagalan—dan terutama tidak harus bergantung pada pengguna untuk menemukan bug itu sendiri. API pengikatan diimplementasikan dengan anotasi Java, yang memungkinkan setiap kelas untuk diikat ke skema JSD(x) dengan tipe yang kuat, namun dengan cara yang ringan. Kemampuan pengikatan dan pembuatan kode yang diketik dengan kuat dari JSONx mendukung cakupan penuh spesifikasi JSD(x), yang dirancang khusus untuk memenuhi standar tinggi untuk solusi perusahaan.

Kerangka kerja JSONx dibuat untuk solusi perusahaan dan menawarkan standar kualitas dan utilitas yang tinggi untuk sistem yang kompleks serta kemudahan penggunaan dan validasi kesalahan waktu edit untuk pengembang.

Mesin pengikat, prosesor, dan validator JSD(x) melaporkan cakupan pengujian 87%, memungkinkan pengembang Java untuk dengan percaya diri mengintegrasikan kerangka kerja untuk mengikat skema JSD(x) ke aplikasi Java mereka dan menyandikan, mendekode, dan memvalidasi dokumen JSON. Untuk melihat lebih dekat kerangka kerja JSONx untuk Java, lihat Kerangka JSONx untuk Java.

Kesimpulan

Dengan melihat lebih dalam sejarah tren web dan perangkat lunak dalam beberapa tahun terakhir, kita dapat melihat hubungan erat antara proliferasi JavaScript dan popularitas JSON. Banyak artikel dan posting blog menawarkan perspektif terbatas ketika membandingkan JSON dan XML, mengarahkan pembaca untuk mengabaikan XML sebagai usang, dan membuat banyak orang tidak menyadari kemampuan hebat yang dapat membantu mereka meningkatkan arsitektur perangkat lunak mereka, ketahanan perangkat lunak mereka terhadap perubahan, dan kualitas keseluruhan dan stabilitas perangkat lunak secara keseluruhan. Dengan evaluasi yang lebih mendalam tentang kekuatan dan kelemahan setiap standar, pengembang dapat diberdayakan untuk membuat keputusan yang lebih baik untuk proyek mereka.

Seperti "bencana divergensi" dengan HTML yang mengarah pada penemuan XML, efek serupa diwujudkan dalam basis kode kompleks yang mengandalkan JSON untuk pertukaran data. Spesifikasi JSON tidak merangkum fungsionalitas langsung seputar pertukaran data, yang dapat menyebabkan fragmentasi logika di lapisan aplikasi yang lebih tinggi. Dengan XML, bagaimanapun, pengembang dapat mendorong kompleksitas seputar pertukaran data ke lapisan bawah aplikasi, menghasilkan kemampuan untuk menangkap bug lebih awal dalam siklus hidup aplikasi. Khusus untuk bahasa yang dikompilasi, dalam kombinasi dengan kerangka kerja pengikatan, arsitektur yang mengandalkan pengikatan XML dapat mengurangi potensi kesalahan terkait data mendekati nol. Untuk perusahaan, kemampuan yang kuat dalam pengurangan sistematis risiko perangkat lunak inilah yang menjadikan XML "cawan suci komputasi."

JSON akan tetap ada, dan beberapa proyek mendapatkan momentum untuk menawarkan kemampuan kuat XML ke JSON. Proyek skema JSON menawarkan spesifikasi skema yang dikembangkan komunitas yang telah berkembang secara organik untuk mendukung berbagai atribut dan pola deklaratif untuk menggambarkan dan membatasi dokumen JSON. Proyek JSONx memberikan bahasa skema tingkat perusahaan yang dirancang sangat mirip dengan bahasa definisi skema XML, dan menawarkan format JSON dan XML untuk spesifikasi dokumen skema JSON. Dengan spesifikasi dan kerangka kerja ini, pengembang dapat mengurangi risiko perangkat lunak yang terkait dengan persyaratan lapisan yang lebih tinggi seputar pertukaran data, seperti kontrak berbasis konsumen, pembuatan versi protokol, validasi konten, dan banyak lagi.

Fitur-fitur canggih XML dirancang untuk mengurangi risiko perangkat lunak yang terkait dengan bahasa markup. Kasus penggunaan dengan JSON tidak berbeda, dan bahasa skema adalah solusi yang telah teruji dan terbukti untuk secara sistematis melindungi berbagai risiko perangkat lunak seputar pertukaran data.

Referensi

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

2. Kesuksesan di Seluruh Dunia Yaitu XML (W3C, Juli 2018)

3. W3C - Apa itu Skema XML? (W3C, Oktober, 2009)

4. Internet: Sebuah Ensiklopedia Sejarah. Kronologi, Jilid 3, hal. 130 (ABC-CLIO, 2005)

5. Skema JSON (Juli 2008)

6. Validator Skema JSON (GitHub)

7. JsonSchema dan SubClassing (Horne, Maret 2016)