نظرة عميقة على JSON مقابل XML ، الجزء 3: XML ومستقبل JSON

في الجزء الثاني من هذه المقالة ، ألقينا نظرة فاحصة على JSON باعتبارها تبادل بيانات وقمنا بتقييم نقاط قوتها وضعفها للتطبيقات البسيطة مقابل المعقدة. يبرز JSON باعتباره التنسيق الأكثر إيجازًا والأكثر إحكاما للقراءة البشرية ، ولكن بساطته الأساسية يمكن أن تؤدي إلى آثار غير مقصودة عند استخدامها في حالات الاستخدام المعقدة. مع JSON لتبادل البيانات ، يتم ترك المطورين بمفردهم لتنفيذ الوظائف المفقودة من JSON نفسها ، مما يؤدي إلى حلول مقترنة وغير قياسية تحاول سد الفجوة. بالنسبة لحلول المؤسسات المصممة على تأكيد التشغيل الخالي من الأخطاء ، قد يؤدي استخدام JSON إلى أنماط غير مرغوب فيها يمكن أن تعرقل جودة رمز النظام واستقراره ومرونته في مواجهة المجهول في المستقبل. هل تقدم XML إمكانيات لمساعدة التطبيقات على التخفيف من هذه المخاطر؟ هل يمكن تحقيق الوظائف نفسها مع JSON؟ إن إلقاء نظرة فاحصة على XML حيث أن تبادل البيانات سيكشف عن نقاط قوتها في تقليل مخاطر البرامج وتزويد المطورين بفهم أفضل للأنماط التي يمكن أن تساعد في تحسين جودة تطبيقاتهم.

في الجزء 3 من هذه المقالة ، سنقوم بما يلي:

1. استكشف XML كوسيلة لتبادل البيانات وتقييم نقاط قوتها في دعم المتطلبات المعقدة.
2. ناقش مستقبل JSON واستكشف الحلول التي تجلب نقاط قوة XML إلى JSON لتمكين المطورين من بناء برامج أكثر استقرارًا وأكثر مقاومة للأخطاء والمجهول في المستقبل.

يتم تصنيف XML بسهولة على أنه البديل المعقد والمطوّل لـ JSON. يقدم موقع الويب w3schools.com - وهو مرجع شائع لمعايير الويب - 58 كلمة فقط حول موضوع "لماذا يعتبر JSON أفضل من XML" ¹ . مثل هذا التقييم المبسط لـ JSON مقابل XML مضلل ، لأن XML يوفر أكثر بكثير من مجرد تبادل البيانات. في الواقع ، لم يتم تصميم XML فقط لتبادل البيانات ، ولكن بدلاً من ذلك كلغة لتحديد لغات الترميز المخصصة لأي تطبيق. مع دلالاتها الصارمة ، حددت XML معيارًا لتأكيد سلامة البيانات في مستندات XML ، لأي لغة فرعية من XML. يعتقد العديد من المطورين أن "XML فشل وتم استبداله بـ JSON" ، لكن هذا أبعد ما يكون عن الحقيقة. في الأصل ، كان من المتصور أن يتم استخدام XML في جميع مشكلات قابلية التشغيل البيني للبيانات ، ولا يزال حتى يومنا هذا "التنسيق الأكثر استخدامًا في العالم لتمثيل المعلومات وتبادلها". ²

JSON بسيط ، و XML قوي

في الجزء الثاني من هذه المقالة ، استكشفنا تبادل البيانات الذي يتضمن العقود التي يحركها المستهلك (CDC) ، وتطور البروتوكول ، والتحقق من صحة الرسائل. مع JSON لتبادل البيانات ، تم تحدي مثالنا - البنك الأوروبي - لتوفير حل مخفف للمخاطر لتبادل البيانات مع تجار التجزئة. رغب البنك في أنماط البرامج التي أدت إلى اقتران منخفض ، وتغليف عالٍ ، ومرونة عالية للمجهول في المستقبل. مع استخدام JSON لتبادل البيانات ، تم تقديم البنك بأنماط تؤدي إلى عكس ذلك: تغليف منخفض ، اقتران عالي ، ومرونة أقل للمجهول في المستقبل.

دعنا نعيد النظر في مثال البنك الأوروبي واستبدال JSON بتنسيق تبادل البيانات بتنسيق XML. رسائل XML التالية مكافئة لرسالة JSON لكل نوع معرف حساب: SWIFT و IBAN و 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>

على الرغم من الخسارة الفورية في كفاءة عدد البايت الخام ، فإن XML يبرر الإسهاب من خلال دعم نطاق أوسع يحيط بتبادل البيانات. من خلال تشفير البيانات باستخدام JSON ، تمكنا من حل المتطلبات الفورية لتبادل البيانات ولكن لا شيء يدعم متغيرات الرسائل المتعددة أو التحقق من صحتها. لمعالجة النطاق المحيط بالعقود التي يحركها المستهلك ، سيحتاج المطورون إلى تنفيذ كود مخصص من شأنه أن يؤدي إلى اقتران منطقي بين تنسيق الرسالة ومحتواها والتنفيذ الوظيفي لمعالجتها. بدلاً من ذلك ، يمكن للمطور اختيار تجميع أحجية مجموعة من المكتبات والأطر معًا لتلبية المتطلبات الأعلى. ينتج عن كلا الأسلوبين بصلة من الطبقات فوق تبادل البيانات المقترنة مباشرة بالتطبيق. ومع ذلك ، فمن خلال ترميز البيانات باستخدام XML ، فإننا قادرون على حل الكثير من نقل المتطلبات بدون أداة الاقتران.

تستخدم مكافئات رسالة XML ميزتين خاصتين لمعيار XML: مساحات الأسماء وأنواع المثيلات. تحدد السمة xmlns="urn:bank:message" مساحة اسم الرسالة ، وتحدد السمة "xsi:type" المثيل الخاص بها ، مثل "swift" أو "iban" أو "ach" . هاتان السمتان هما معايير XML التي تسمح لمعالج الرسائل بتحديد نوع الرسالة بالإضافة إلى عدم الإشارة إلى المخطط الذي يحدد قواعد التحقق من الصحة.

يمثل مخطط XML أداة التمييز الرئيسية بين JSON و XML. باستخدام المخطط ، يمكن للمطور تغليف التعريف المعياري لتنسيق الرسالة في وسيط منفصل عن التطبيق وتحديد قيود القيمة التي توفر قواعد التحقق من الصحة التي تفرضها معالجات XML. مثال على مخطط للبنك الأوروبي (مع namespace: xmlns="urn:bank:message" ) ، مكتمل مع واصفات النوع وقيود القيمة ، هو مستند مخطط 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>

مخطط XML هذا مكافئ منطقيًا لوظيفة isValid(message) من الجزء 2. عند أول استحى ، يكون مخطط XML هذا مطولًا بشكل ملحوظ أكثر من isValid(message) . ومع ذلك ، فإن الاختلاف الأساسي بين الاثنين هو أن isValid(message) مقترن بالتطبيق ، ومخطط XML ليس كذلك. مخطط XML هو لغة للتعبير عن القيود المتعلقة بمستندات XML وهناك العديد من لغات المخططات المختلفة المستخدمة على نطاق واسع ، وأهمها: تعريفات نوع المستند (DTDs) و Relax-NG و Schematron و W3C XML لتعريفات (XSD ). ³ بالنسبة للبنك الأوروبي ، يوفر مخطط XML حلاً مخففاً للمخاطر لمتطلبات الطبقة الأعلى بدون أداة الاقتران.

مخطط XML ينتج عنه مخاطر أقل للبرامج. باستخدام XML ، يتم التعبير عن قواعد التحقق من صحة الرسائل بلغة مخطط مفصولة عن التطبيق ، وبالتالي غير مقترنة به. نظرًا لأن مخطط XML منفصل تمامًا عن النظام ، يتم فصل المعنى المنطقي لتنسيق الرسالة والتنفيذ الوظيفي لمعالجته. يوفر مخطط XML للبنك الأوروبي طبقة مغلفة تكون مسؤولة بمفردها عن سياق التحقق من صحة الرسالة والتنوع وإصدار الإصدار وغير ذلك.

يمثل مخطط XML التعريف المعياري للعقد الذي يحركه المستهلك. بالنسبة للبنك الأوروبي ، يوفر هذا نهجًا مخففًا للمخاطر لتقليل $ \ xi_0 $ أقرب إلى الصفر. نظرًا لأن المخطط مفصول عن البنك وبائع التجزئة ، يمكن لكلا الطرفين استخدامه للتحقق من صحة العقد وإنفاذه.

لماذا مخطط XML مطول للغاية؟

توفر مواصفات مخطط XML لغة للمطورين لتنفيذ الأنماط الهيكلية والمنطقية المستخدمة لتحديد وتقييد جميع الأجزاء المكونة لأي مستند XML. باستخدام مخطط XML ، يستطيع المطورون تضمين معنى أعمق في كل جزء هيكلي ومنطقي من مستند XML. على سبيل المثال ، يسمح مخطط XML بما يلي:

1. تعريف قيود التعبير العادي للسلاسل المكونة ،
2. تعريف النطاقات والصيغ للأرقام المكونة ،
3. تحديد العناصر والصفات المكونة المطلوبة والاختيارية ،
4. تحديد المتطلبات الأساسية والمرجعية في مستند ، وأكثر من ذلك بكثير.

باستخدام مخطط XML ، يمكن للنظام الاعتماد على مدققات XML العامة لتأكيد صحة كل رسالة إدخال ، مما يقلل بشكل جوهري من "مساحة الخطأ" $ \ xi_0 $ أقرب إلى الصفر ويعزل منطق الأعمال تلقائيًا عن المدخلات الخاطئة.

مخاطر التنمية المستقبلية

يمكن للأنظمة استخدام الميزات المتأصلة في مواصفات XML لتقليل مخاطر البرامج في التطوير المستقبلي. بالموافقة على عقد معياري في شكل مخطط XML ، تحدد الأنظمة القواعد والقيود لجميع الكائنات والخصائص (العناصر والسمات ، لـ XML) ليتم تبادلها. أصبحت الأنظمة بعد ذلك قادرة على الاستفادة من النطاق الأوسع لمواصفات XML لمعالجة تغير الرسائل ، وإصدار البروتوكول ، والتحقق من صحة المحتوى. على سبيل المثال ، توفر مساحات أسماء XML رسائل XML بالمعلومات اللازمة من أجل:

1. حدد إصدار الرسالة.
2. اشتقاق مخطط العقد المعياري.
3. التحقق من صحة الوثيقة.

مع اتساع نطاق الميزات والإمكانيات التي يوفرها مخطط XML ، يمكن حل معظم المتطلبات المعقدة المحيطة بتبادل البيانات باستخدام XML نفسه. هذا ما كان يشير إليه الدكتور تشارلز جولدفارب عندما قال "[XML هو] الكأس المقدسة للحوسبة." ⁴

يساعد مخطط XML التطبيقات على أن تكون مرنة تجاه الأخطاء وقابلة للتكيف مع التغييرات المستقبلية.

تعد XML من المواصفات المقبولة على نطاق واسع والتي تم فحصها بدقة مع عدد لا يحصى من المكتبات المتاحة لجميع الأنظمة الأساسية للمساعدة في معالجة مستندات XML والتحقق من صحتها. باستخدام XML كتنسيق تبادل البيانات ، يكون المطور قادرًا على حل المتطلبات الفورية وكذلك تلك المتعلقة بالعقود التي يقودها المستهلك ، وتغير الرسائل ، وإصدار البروتوكول ، والتحقق من صحة المحتوى. يُمكّن XML المطور من التحوط من مخاطر المتطلبات المعقدة ، والأهم من ذلك ، المخاطر المجهولة في المستقبل.

XML هو أكثر بكثير من مجرد تبادل البيانات ويمكن استخدامه لمعالجة مشاكل أكبر بكثير من مع JSON. عند النظر إليه من هذا المنظور ، فإن نطاق XML يغطي جزءًا أكبر من البصلة ، حيث يتم تضمين العديد من طبقات البصل في نطاق XML نفسه.

عند اختيار أفضل تنسيق لتبادل البيانات لأحد التطبيقات ، هل هو فقط مركز البصل الذي نهتم به ، أم أنه البصلة بأكملها؟

الاختلافات الأساسية بين JSON و XML

يقدم XML أكثر بكثير من تبادل البيانات ويمكن استخدامه لمعالجة مشاكل أكبر بكثير من JSON. يتم استيعاب نطاق المتطلبات المعقدة المحيطة بتبادل البيانات بواسطة XML ، مما يسمح للأنظمة باستخدام المكتبات والأطر المطابقة لمعيار ، منفصلة عن التطبيق.

XML هي مواصفة تتناول نطاق المتطلبات المعقدة حسب التصميم وهي معيار تم تحديده بواسطة W3C ومدعوم من قبل جميع بائعي البرامج والأنظمة الأساسية اللغوية ذات الصلة. باستخدام XML لتبادل البيانات ، تستفيد التطبيقات تلقائيًا من تقليل مخاطر البرامج بشكل منهجي.

مستقبل JSON

JSON هنا لتبقى بلا شك. مع JavaScript باعتباره النظام الأساسي للتطوير الأكثر استخدامًا اليوم ، أصبح JSON هو تنسيق تبادل البيانات الأبرز. بالنسبة للمشاريع الصغيرة ذات التعقيد المنخفض ، فإن JSON مناسبة تمامًا. ولكن بينما نسعى لإنشاء تطبيقات أكبر وأفضل للمستقبل ، فإن التعقيد العام لبرنامجنا مقدر له أن يزداد. مع الإمكانات القوية لـ XML كمثال ، سعت عدة مجموعات لابتكار معايير مماثلة لـ JSON.

يتمثل النقص الأساسي في JSON في افتقارها إلى توفير معيار عام للوصف المعياري للمكونات المنطقية لوثائقها.

مخطط JSON

في عام 2009 ، بدأت المجموعة مخطط JSON ⁵ ، وهو عبارة عن مفردات للتعليق والتحقق من مستندات JSON. يستخدم مخطط JSON دلالات JSON لتحديد مجموعة من القواعد والقيود لمكونات مستندات JSON ، وقد نفذت العديد من المشاريع على أنظمة أساسية مختلفة مكتبات تدعم مواصفات مخطط JSON. على الرغم من أنه ليس معيارًا رسميًا بعد ، فإن مشروع مخطط JSON يوفر حلاً لنطاق من المتطلبات يشبه مواصفات مخطط XML. باستخدام مفردات مخطط JSON ، يمكن للمطورين تحديد القواعد والقيود المنطقية والهيكلية لوثائق JSON. يمكن بعد ذلك استخدام المخطط للمساعدة في معالجة والتحقق من صحة مستندات JSON مع المكتبات المنفصلة عن التطبيق ، وبالتالي تقليل الحاجة إلى اختلاط التعليمات البرمجية غير المغلفة في التطبيق. باستخدام مخطط JSON ، يمكن للمطور اختيار JSON كتنسيق لتبادل البيانات وعنوانه ، بطريقة مخففة للمخاطر ، المتطلبات المعقدة التي لم يكن من الممكن معالجتها مسبقًا باستخدام JSON وحده.

مشروع مخطط JSON هو جهد مجتمعي ، وبعد عقد من المراجعات ، يقف باعتباره المواصفات السائدة لمخططات JSON. على الرغم من أنه ليس معيارًا بعد ، إلا أن شعبية مشروع مخطط JSON تشير إلى مستوى الاهتمام بمثل هذا الحل. من الناحية المفاهيمية ، تشبه مواصفات مخطط JSON مخطط XML ، لكن المقارنة بين الاثنين تكشف عن الاختلافات بين النماذج والقدرات والدلالات. على سبيل المثال ، على الرغم من أن اللغة تحدد نطاقًا واسعًا من الخصائص لتقييد حدود أنواع قيم JSON ، إلا أن سماتها العديدة تسمح بالتعبير عن تعريفات المخططات المتناقضة ذاتيًا.

على سبيل المثال ، يحدد المقتطف التالي نوع "object" الذي يحتوي على ثلاث خصائص: "number" و "street_name" و "street_type" .

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

يقبل تعريف نوع "object" قيودًا إضافية ، أحدها "minProperties" . من خلال تعديل تعريف نوع "object" أعلاه باستخدام "minProperties": "4" ، يصبح التعريف غير منطقي ، لأنه تم تحديد ثلاث خصائص فقط بشكل صريح للكائن.

يحتوي مخطط JSON على عدد كبير وواسع من خصائص القيود ، والعديد منها ضروري لتقييد مستندات JSON بشكل فعال ، والعديد منها يتداخل مع بعضها البعض. مع خصائص القيد التي تتداخل في المعنى ، تقدم مفردات مخطط JSON عائلتين من التحديات:

1. إنها تتطلب منحنى تعليميًا عاليًا من المطورين ، بسبب المفردات الواسعة والفروق الدقيقة غير العادية أو غير التقليدية في دلالاتها.
2. يصعب تنفيذ مكتبات التحقق من الصحة ، مما يؤدي إلى حلول تقوم بتنفيذ المناطق الرمادية بشكل مختلف ، مما يؤدي إلى عمليات تنفيذ غير متسقة.

لغة مخطط XML في حد ذاتها ليست خالية تمامًا من السماح بالتعبير عن التعاريف المتناقضة مع الذات ، لكنها أقل بكثير ومحدودة. في الواقع ، تم تطوير مواصفات مخطط XML مع الاهتمام الشديد بكل من سهولة الاستخدام للمطورين وكذلك للمكتبات التي تطبق المواصفات. علاوة على ذلك ، فإن مشروع مخطط JSON يحدد فقط مواصفات لغة المخطط ، ولكن توجد العديد من مشاريع المجتمع التي تنفذ هذه المواصفات.

يعد مدقق مخطط JSON ⁶ مشروعًا شائعًا يقوم بتنفيذ مدقق مخطط JSON لمنصة Java الأساسية. من خلال دمج هذه المكتبة في تطبيق Java ، يكون التطبيق قادرًا على تأكيد توافق جميع مستندات JSON المتبادلة. تتوفر تطبيقات أخرى لمواصفات مخطط JSON لمجموعة متنوعة من الأنظمة الأساسية.

بالنسبة للبنك الأوروبي ، دعنا نستخدم مخطط JSON لتنفيذ مخطط لرسائل JSON مع معرفات الحساب.

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

يحدد مخطط JSON هذا ثلاثة أنواع من الكائنات: "swift" و "iban" و "ach" . تحدد أنماط التعبير العادي لتأكيد أن معلومات الحساب غير صالحة ، وتعلن "type" و "code" كخصائص مطلوبة لكل نوع ، بالإضافة إلى "routing" كخاصية مطلوبة لنوع "ach" . باستخدام مخطط JSON هذا ، يمكن للبنك الأوروبي التحقق من صحة إدخال JSON لتأكيد صحة محتوى الرسالة لكل تفاعل.

يجلب مخطط JSON العديد من إمكانيات XML إلى JSON ، لكنه لا يزال قيد التقدم. على الرغم من أنه حل رائع يمكن استخدامه للتحوط من مخاطر البرامج ، إلا أن مواصفات مخطط JSON ليست مثالية. نظرًا للتطور غير الرسمي للغة ، فقد تطورت اللغة في اتجاه يحذف ميزات يمكن القول إنها مهمة ويحتوي على أنماط تعبير هيكلية ومنطقية مربكة وغير تقليدية. على سبيل المثال ، تفتقد لغة المخطط إلى القدرة على تحديد أنواع مجردة ، والتي يمكن أن تقود المطورين إلى تنفيذ الحلول المعقدة التي تؤدي إلى مخاطر البرامج المرتبطة بها. ⁷

جلب مشروع مخطط JSON ثروة لا تقدر بثمن من المساهمة في المفاهيم الكامنة وراء لغة المخطط لـ JSON. على الرغم من أوجه القصور في وضوح دلالاتها ، فإن لغة مخطط JSON هي حل متعدد الاستخدامات يوفر العديد من إمكانيات XML إلى JSON.

لإلقاء نظرة فاحصة على مواصفات مخطط JSON ، راجع فهم مخطط JSON.

JSONx

في عام 2014 ، بدأت مجموعة أخرى مشروع JSONx ، والذي يستفيد بشكل مباشر من XML لتوفير حل قوي مماثل لـ JSON. تم إنشاء مشروع JSONx خصيصًا للمؤسسة ، ويحدد لغة تعريف مخطط JSON (JSD) ، والتي تم نمذجتها بشكل وثيق مع مواصفات مخطط XML. باستخدام مخطط XML كنموذج لها ، تحدد JSD الأنماط الهيكلية والمنطقية التي تشبه إلى حد بعيد لغة تعريف مخطط XML.

بالنسبة لمثال البنك الأوروبي ، دعنا نستخدم لغة JSD لتنفيذ مخطط لرسائل JSON مع معرفات الحساب.

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

للوهلة الأولى ، يتشابه مخطط JSD في التعبير عن مخطط JSON. ومع ذلك ، فإن أحد الاختلافات هو الدلالات المختصرة لـ JSD مقارنة بمخطط JSON. تحديدًا لهذا المثال ، تضع JSD خاصية "use": "required" في التعريف الذي يتم تحديده ، بينما يربط مخطط JSON هذه الخاصية بالعنصر الرئيسي ، مما يتطلب اسم القيم لمطابقة اسم تعريف الخاصية. القيد "use": "required" محدد فقط في خاصية "code" للكائن "swift" وتم حذفه من العناصر الأخرى لأن "use": "required" هي القيمة الافتراضية. تم تصميم لغة JSD مع مراعاة كل هذه الفروق الدقيقة وتوفر حلاً نظيفًا وبديهيًا للتعبير عن مخططات JSON.

منذ البداية ، الخاصية المميزة لمشروع JSONx هي نيته الأساسية لتوفير الوضوح والمنفعة للمطورين. لتحقيق ذلك ، فإن الميزة القوية لـ JSD هي قابليتها للتحويل إلى JSDx - يمكن التعبير عن لغة JSD في ملفات JSON وكذلك ملفات XML. كلا النموذجين قابلان للترجمة واحد لواحد ويوفران للمطورين القدرة على استخدام أدوات تحرير XML المتقدمة للمساعدة في إنشاء مستندات JSD ليتم التحقق من صحتها مباشرة وخالية من الأخطاء.

يمكن التعبير عن مخطط JSD أعلاه في نموذج 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>

شكل JSDx من JSD قوي لأنه يوفر مواصفات واضحة ، ذاتية التحقق من الصحة ، ومحدودة المخاطر لتحديد مخططات JSON.

تم تصميم لغة JSD لمعالجة مخاوف التعاريف المتناقضة ، وتعتمد على الأنماط القياسية للتعبير عن القيود. تم تصميمه بشكل مشابه جدًا للغة تعريف مخطط XML (XSD) ، إعلانات نوع JSD وتعريفات للقيود تشبه إلى حد بعيد الهياكل المكافئة في XML. توفر مواصفات JSD (x) حلاً كاملاً لتعريف القيود الهيكلية والمنطقية ، وهي ذاتية الوصف - توفر تعريفًا معياريًا للغة JSD (x) معبرًا عنها بلغة JSD (x) نفسها. لإلقاء نظرة فاحصة على مواصفات JSD (x) ، راجع لغة تعريف مخطط JSON.

بالإضافة إلى لغة JSD (x) ، يوفر مشروع JSONx تطبيقات مرجعية لمعالجات ومدققات JSD (x) بالإضافة إلى واجهة برمجة تطبيقات ملزمة للفئة ومولد رمز لمنصة Java. باستخدام واجهة برمجة التطبيقات والمُنشئ للربط ، يمكن للمطور استخدام مخطط JSD (x) لإنشاء فئات لتعريفات الكائنات في المخطط المطلوب ، والتي يمكن استخدامها لتحليل وتنظيم مستندات JSON التي تتوافق مع المخطط. توفر الفئات التي تم إنشاؤها ارتباطًا مكتوبًا بشدة بين المخطط ونظام Java الأساسي ، مما يمثل الاستخدام والقيود والعلاقات المحددة في مخطط قاعدة البيانات. من خلال الارتباطات المكتوبة بشدة بالمخطط ، يقلل التطبيق بشكل أكبر من مخاطر البرامج المتعلقة بالتعديلات المستقبلية التي قد تؤدي إلى حالات عدم التوافق.

من خلال الاستفادة من مترجم Java ، تحدد الارتباطات المكتوبة بشدة حالات عدم التوافق مع أخطاء وقت الترجمة ، مما يقلل بشكل فعال من مخاطر الأخطاء المتعلقة بمعالجة الرسائل التي تقترب من الصفر. يمكّن هذا النمط الهندسي المطورين من تنفيذ التغييرات وحل حالات عدم التوافق بسرعة وثقة ، وعدم الاضطرار إلى الاعتماد على وقت التشغيل للعثور على الأخطاء أو حالات الفشل - وخاصة عدم الاضطرار إلى الاعتماد على المستخدمين لتعثر الأخطاء بأنفسهم. يتم تنفيذ واجهة برمجة التطبيقات (API) الملزمة مع تعليقات Java التوضيحية ، والتي تسمح لأي فئة بأن تكون مرتبطة بمخطط JSD (x) بأنواع قوية ، ولكن بطريقة خفيفة الوزن. تدعم إمكانات إنشاء الروابط والتعليمات المكتوبة بشدة لـ JSONx النطاق الكامل لمواصفات JSD (x) ، المصممة خصيصًا لتلبية المعايير العالية لحلول المؤسسات.

تم إنشاء إطار عمل JSONx لحلول المؤسسات ويقدم مستوى عاليًا من الجودة والمنفعة للأنظمة المعقدة بالإضافة إلى سهولة الاستخدام والتحقق من أخطاء وقت التحرير للمطورين.

محرك ربط JSD (x) والمعالج وتقرير المدقق تغطية اختبار 87٪ ، مما يسمح لمطوري Java بدمج إطار العمل بثقة لربط مخططات JSD (x) بتطبيقات Java الخاصة بهم وترميز مستندات JSON وفك تشفيرها والتحقق من صحتها. لإلقاء نظرة فاحصة على إطار عمل JSONx لجافا ، راجع إطار عمل JSONx لجافا.

خاتمة

بإلقاء نظرة أعمق على تاريخ الويب واتجاهات البرامج في السنوات الأخيرة ، يمكننا أن نرى علاقة وثيقة بين انتشار JavaScript وشعبية JSON. تقدم العديد من المقالات ومنشورات المدونات منظورًا محدودًا عند مقارنة JSON و XML ، مما يدفع القراء إلى اعتبار XML قديمًا ، وترك الكثيرين غير مدركين للإمكانيات القوية التي قد تساعدهم على تحسين بنية برامجهم ، ومرونة برامجهم للتغيير ، والجودة الشاملة و استقرار البرنامج ككل. من خلال تقييم أعمق لنقاط القوة والضعف في كل معيار ، يمكن تمكين المطورين لاتخاذ قرارات أفضل لمشاريعهم.

مثل "كارثة الاختلاف" مع HTML التي أدت إلى اختراع XML ، يتم تحقيق تأثير مماثل في قواعد الرموز المعقدة التي تعتمد على JSON لتبادل البيانات. لا تلخص مواصفات JSON الوظائف الفورية المحيطة بتبادل البيانات ، مما قد يؤدي إلى تجزئة المنطق في الطبقات العليا من التطبيق. مع XML ، يمكن للمطورين دفع التعقيد المحيط بتبادل البيانات إلى الطبقات السفلية من التطبيق ، مما يؤدي إلى القدرة على اكتشاف الأخطاء في وقت مبكر من دورة حياة التطبيق. خاصة بالنسبة للغات المترجمة ، جنبًا إلى جنب مع إطار عمل ملزم ، يمكن للبنى التي تعتمد على ربط XML أن تقلل من احتمالية حدوث أخطاء متعلقة بالبيانات قريبة من الصفر. بالنسبة للمؤسسة ، فإن هذه الإمكانات القوية في التقليل المنهجي لمخاطر البرامج هي التي تجعل XML "الكأس المقدسة للحوسبة".

JSON موجود لتبقى ، وتكتسب العديد من المشاريع زخمًا لتقديم الإمكانات القوية لـ XML إلى JSON. يقدم مشروع مخطط JSON مواصفات مخطط تم تطويرها من قِبل المجتمع والتي نمت بشكل عضوي لدعم مجموعة واسعة من السمات والأنماط التصريحية لوصف مستندات JSON وتقييدها. يقدم مشروع JSONx لغة مخطط على مستوى المؤسسة تم تصميمها على نحو يشبه إلى حد بعيد لغة تعريف مخطط XML ، ويقدم تنسيقات JSON و XML لمواصفات مستندات مخطط JSON. باستخدام هذه المواصفات والأطر ، يمكن للمطورين تقليل مخاطر البرامج المتعلقة بمتطلبات الطبقة العليا المحيطة بتبادل البيانات ، مثل العقود التي يقودها المستهلك ، وإصدار البروتوكول ، والتحقق من صحة المحتوى ، والمزيد.

تم تصميم الميزات المتقدمة لـ XML للتخفيف من مخاطر البرامج المتعلقة بلغات الترميز. لا تختلف حالات الاستخدام مع JSON ، وتعتبر لغة المخطط حلاً مجربًا ومثبتًا بالوقت للتحوط المنتظم لمجموعة واسعة من مخاطر البرامج المحيطة بتبادل البيانات.

مراجع

1. JSON مقابل XML (w3schools.com ، كانون الأول (ديسمبر) 2016)

2. النجاح العالمي هو XML (W3C ، يوليو 2018)

3. W3C - ما هو مخطط XML؟ (W3C ، أكتوبر ، 2009)

4. الإنترنت: موسوعة تاريخية. التسلسل الزمني ، المجلد 3 ، ص. 130 (ABC-CLIO، 2005)

5. مخطط JSON (يوليو 2008)

6. مدقق مخطط JSON (GitHub)

7. JsonSchema و SubClassing (Horne ، مارس 2016)