เจาะลึก JSON กับ XML ตอนที่ 3: XML และอนาคตของ JSON

ในส่วนที่ 2 ของบทความนี้ เราได้พิจารณา 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 นั้นทรงพลัง

ในส่วนที่ 2 ของบทความนี้ เราได้สำรวจการแลกเปลี่ยนข้อมูลที่เกี่ยวข้องกับสัญญาที่ขับเคลื่อนโดยผู้บริโภค (CDC) วิวัฒนาการของโปรโตคอล และการตรวจสอบความถูกต้องของข้อความ ด้วย JSON เป็นการแลกเปลี่ยนข้อมูล ตัวอย่างของเรา—ธนาคารยุโรป—ถูกท้าทายในการจัดหาโซลูชันที่ช่วยลดความเสี่ยงสำหรับการแลกเปลี่ยนข้อมูลกับผู้ค้าปลีก ธนาคารต้องการรูปแบบซอฟต์แวร์ที่ส่งผลให้มี coupling ต่ำ มีการห่อหุ้มสูง และมีความยืดหยุ่นสูงต่อสิ่งที่ไม่รู้จักในอนาคต อย่างไรก็ตาม ด้วย 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 schema (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 schema ไม่ใช่ สคีมา XML เป็นภาษาสำหรับแสดงข้อจำกัดเกี่ยวกับเอกสาร XML และมีภาษาสคีมาที่แตกต่างกันหลายภาษาที่ใช้กันอย่างแพร่หลาย ภาษาหลัก ได้แก่: คำจำกัดความของประเภทเอกสาร (DTDs), Relax-NG, Schematron และ W3C XML schema definitions (XSD) ). ³ สำหรับธนาคารยุโรป สคีมา XML มอบโซลูชันที่ลดความเสี่ยงสำหรับข้อกำหนดระดับสูงกว่าโดยไม่ต้องมีการเชื่อมต่อ

สคีมา XML ส่งผลให้ความเสี่ยงด้านซอฟต์แวร์ลดลง ด้วย XML กฎสำหรับการตรวจสอบความถูกต้องของข้อความจะแสดงเป็นภาษาสคีมาที่ไม่เกี่ยวข้อง และไม่เชื่อมโยงกับแอปพลิเคชัน เนื่องจาก XML schema ถูกแยกออกจากระบบอย่างสมบูรณ์ ความหมายเชิงตรรกะของรูปแบบข้อความและการใช้งานฟังก์ชันสำหรับการประมวลผลจะถูกแยกออก สคีมา XML ช่วยให้ธนาคารยุโรปมีเลเยอร์ที่ห่อหุ้มซึ่งมีหน้าที่รับผิดชอบแต่เพียงผู้เดียวสำหรับบริบทของการตรวจสอบความถูกต้องของข้อความ ความแปรปรวน การกำหนดเวอร์ชัน และอื่นๆ

สคีมา XML แสดงถึงคำจำกัดความเชิงบรรทัดฐานของสัญญาที่ขับเคลื่อนโดยผู้บริโภค สำหรับธนาคารยุโรป วิธีนี้เป็นแนวทางลดความเสี่ยงเพื่อลด $\xi_0$ ให้เข้าใกล้ 0 เนื่องจากสคีมาแยกออกจากธนาคารและผู้ค้าปลีก ทั้งสองฝ่ายจึงสามารถใช้แผนนี้เพื่อตรวจสอบและบังคับใช้สัญญาได้

เหตุใด XML Schema จึงละเอียดมาก?

ข้อกำหนด XML schema จัดเตรียมภาษาสำหรับนักพัฒนาเพื่อใช้รูปแบบโครงสร้างและตรรกะที่ใช้ในการกำหนดและเพื่อจำกัดองค์ประกอบทั้งหมดของเอกสาร XML ใดๆ ด้วย XML schema นักพัฒนาสามารถฝังความหมายที่ลึกซึ้งขึ้นในแต่ละส่วนโครงสร้างและตรรกะของเอกสาร XML ตัวอย่างเช่น สคีมา XML อนุญาตให้:

1. คำจำกัดความของข้อจำกัดนิพจน์ทั่วไปสำหรับสตริงที่เป็นส่วนประกอบ
2. คำจำกัดความของช่วงและรูปแบบสำหรับหมายเลขส่วนประกอบ
3. คำจำกัดความขององค์ประกอบและแอตทริบิวต์ที่จำเป็นและเป็นทางเลือก
4. คำจำกัดความของข้อกำหนดที่สำคัญและการอ้างอิงในเอกสาร และอื่นๆ อีกมากมาย

ด้วยสคีมา XML ระบบสามารถพึ่งพาตัวตรวจสอบ XML ทั่วไปเพื่อยืนยันความถูกต้องของข้อความอินพุตแต่ละข้อความ โดยลด "พื้นที่ข้อผิดพลาด" $\xi_0$ ให้ใกล้เคียงกับ 0 และป้องกันตรรกะทางธุรกิจโดยอัตโนมัติจากอินพุตที่ผิดพลาด

ความเสี่ยงของการพัฒนาในอนาคต

ระบบสามารถใช้คุณลักษณะโดยธรรมชาติของข้อกำหนด XML เพื่อลดความเสี่ยงของซอฟต์แวร์ในการพัฒนาในอนาคต โดยการยอมรับสัญญาเชิงบรรทัดฐานในรูปแบบของ XML schema ระบบกำหนดกฎและข้อจำกัดสำหรับอ็อบเจ็กต์และคุณสมบัติทั้งหมด (องค์ประกอบและแอตทริบิวต์ สำหรับ XML) ที่จะแลกเปลี่ยนกัน หลังจากนั้น ระบบจะสามารถใช้ประโยชน์จากขอบเขตที่กว้างขึ้นของข้อกำหนดของ XML เพื่อจัดการกับความแปรปรวนของข้อความ การกำหนดเวอร์ชันของโปรโตคอล และการตรวจสอบความถูกต้องของเนื้อหา ตัวอย่างเช่น เนมสเปซ XML จัดเตรียมข้อความ XML พร้อมข้อมูลที่จำเป็นเพื่อ:

1. ระบุเวอร์ชันของข้อความ
2. อ้างอิงสคีมาสัญญาเชิงบรรทัดฐาน
3. ตรวจสอบความถูกต้องของเอกสาร

ด้วยคุณสมบัติและความสามารถที่หลากหลายที่นำเสนอโดย XML schema ข้อกำหนดที่ซับซ้อนโดยรอบการแลกเปลี่ยนข้อมูลส่วนใหญ่สามารถแก้ไขได้ด้วย XML เอง นี่คือสิ่งที่ Dr. Charles Goldfarb กล่าวถึงเมื่อเขากล่าวว่า "[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 schema ⁵ ซึ่งเป็นคำศัพท์สำหรับใส่คำอธิบายประกอบและตรวจสอบเอกสาร 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 schema ได้รับการพัฒนาโดยให้ความสนใจอย่างใกล้ชิดกับทั้งความง่ายในการใช้งานสำหรับนักพัฒนาและสำหรับไลบรารีที่ใช้ข้อกำหนดนี้ นอกจากนี้ โปรเจ็กต์สคีมา JSON จะกำหนดข้อกำหนดเฉพาะของภาษาสคีมาเท่านั้น แต่มีโปรเจ็กต์ชุมชนจำนวนมากที่ใช้ข้อกำหนดนี้

เครื่องมือตรวจสอบสคีมา JSON ⁶ เป็นโปรเจ็กต์ยอดนิยมที่ใช้ตัวตรวจสอบสคีมา JSON สำหรับแพลตฟอร์ม Java ด้วยการรวมไลบรารีนี้ในแอปพลิเคชัน Java แอปพลิเคชันสามารถยืนยันความสอดคล้องของเอกสาร JSON ทั้งหมดที่แลกเปลี่ยนกัน การใช้งานอื่นๆ ของข้อกำหนดสคีมา JSON มีให้ในหลากหลายแพลตฟอร์ม

สำหรับธนาคารยุโรป ลองใช้ JSON schema เพื่อใช้ schema สำหรับข้อความ 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 นี้กำหนดประเภทอ็อบเจ็กต์ 3 ประเภท: "swift" , "iban" และ "ach" ระบุรูปแบบนิพจน์ทั่วไปเพื่อยืนยันว่าข้อมูลบัญชีไม่ถูกต้อง และประกาศ "type" และ "code" เป็นคุณสมบัติที่จำเป็นสำหรับแต่ละประเภท นอกเหนือจาก "routing" เป็นคุณสมบัติที่จำเป็นสำหรับประเภท "ach" ด้วยสคีมา JSON นี้ ธนาคารยุโรปสามารถตรวจสอบการป้อนข้อมูล JSON เพื่อยืนยันว่าเนื้อหาข้อความถูกต้องสำหรับทุกการโต้ตอบ

สคีมา JSON นำความสามารถมากมายของ XML มาสู่ JSON แต่ก็ยังอยู่ในระหว่างดำเนินการ แม้ว่าจะเป็นโซลูชันที่ยอดเยี่ยมที่สามารถใช้เพื่อป้องกันความเสี่ยงของซอฟต์แวร์ แต่ข้อกำหนดสคีมา JSON ก็ยังไม่สมบูรณ์แบบ เนื่องจากวิวัฒนาการของภาษาอย่างไม่เป็นทางการ ภาษาจึงมีการพัฒนาไปในทิศทางที่ละเว้นคุณลักษณะที่สำคัญซึ่งมีเนื้อหาเป็นเนื้อหา และมีรูปแบบการแสดงออกทางโครงสร้างและตรรกะที่สร้างความสับสนและแปลกใหม่ ตัวอย่างเช่น ภาษาสคีมาขาดความสามารถในการกำหนดประเภทนามธรรม ซึ่งอาจทำให้นักพัฒนาใช้วิธีแก้ไขปัญหาเฉพาะหน้าที่ซับซ้อน ซึ่งส่งผลให้เกิดความเสี่ยงด้านซอฟต์แวร์ที่เกี่ยวข้องด้วยตัวมันเอง ⁷

โปรเจ็กต์สคีมา JSON ได้นำความมั่งคั่งอันมีค่ามาสนับสนุนแนวคิดเบื้องหลังภาษาสคีมาสำหรับ JSON แม้จะมีข้อบกพร่องในความชัดเจนของความหมาย แต่ภาษาสคีมา JSON ก็เป็นโซลูชันอเนกประสงค์ที่นำความสามารถมากมายของ XML มาสู่ JSON

หากต้องการดูข้อกำหนดสคีมา JSON อย่างละเอียดยิ่งขึ้น โปรดดูที่ การทำความเข้าใจ JSON Schema

JSONx

ในปี 2014 อีกกลุ่มหนึ่งเริ่มโครงการ JSONx ซึ่งใช้ประโยชน์จาก XML โดยตรงเพื่อมอบโซลูชันที่มีประสิทธิภาพเท่าเทียมกันสำหรับ JSON โปรเจ็กต์ JSONx สร้างขึ้นสำหรับองค์กรโดยเฉพาะ และกำหนดภาษาคำจำกัดความสคีมา JSON (JSD) ซึ่งจำลองแบบใกล้เคียงกับข้อกำหนดสคีมา XML การใช้ XML schema เป็นโมเดล JSD กำหนดรูปแบบโครงสร้างและตรรกะที่มีความคล้ายคลึงอย่างใกล้ชิดกับภาษาข้อกำหนด XML schema

สำหรับตัวอย่างธนาคารยุโรป ลองใช้ภาษา 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 schema (XSD) อย่างใกล้ชิด การประกาศประเภท JSD และคำจำกัดความของข้อจำกัดมีความคล้ายคลึงอย่างใกล้ชิดกับโครงสร้างที่เทียบเท่าใน XML ข้อกำหนด JSD(x) ให้โซลูชันที่สมบูรณ์สำหรับคำจำกัดความของข้อจำกัดเชิงโครงสร้างและตรรกะ และเป็นการอธิบายตนเอง—ให้คำจำกัดความเชิงบรรทัดฐานของภาษา JSD(x) ที่แสดงในภาษา JSD(x) เอง หากต้องการดูข้อกำหนด JSD(x) อย่างละเอียดยิ่งขึ้น โปรดดูที่ JSON Schema Definition Language

นอกเหนือจากภาษา JSD(x) แล้ว โปรเจ็กต์ JSONx ยังมีการใช้งานอ้างอิงของตัวประมวลผลและตัวตรวจสอบความถูกต้อง JSD(x) รวมถึง API การโยงคลาสและตัวสร้างโค้ดสำหรับแพลตฟอร์ม Java API และตัวสร้างการเชื่อมโยง นักพัฒนาสามารถใช้สคีมา JSD(x) เพื่อสร้างคลาสอัตโนมัติสำหรับคำจำกัดความอ็อบเจ็กต์ในสคีมาที่ต้องการ ซึ่งสามารถใช้เพื่อแยกวิเคราะห์และจัดการเอกสาร JSON ที่สอดคล้องกับสคีมา คลาสที่สร้างขึ้นจัดเตรียมการเชื่อมโยงระหว่างสคีมาและแพลตฟอร์ม Java อย่างแน่นหนา ซึ่งแสดงถึงการใช้งาน ข้อจำกัด และความสัมพันธ์ที่ระบุในสคีมา ด้วยการเชื่อมโยงแบบพิมพ์อย่างแน่นหนากับสคีมา แอปพลิเคชันจะช่วยลดความเสี่ยงของซอฟต์แวร์ที่เกี่ยวข้องกับการปรับเปลี่ยนในอนาคตที่อาจส่งผลให้เกิดความไม่ลงรอยกันได้

ด้วยการใช้ประโยชน์จากคอมไพเลอร์ของ Java การเชื่อมโยงที่พิมพ์อย่างแน่นหนาจะชี้ให้เห็นถึงความไม่ลงรอยกันของข้อผิดพลาดในการคอมไพล์ ลดความเสี่ยงสำหรับจุดบกพร่องที่เกี่ยวข้องกับการประมวลผลข้อความที่เกือบเป็นศูนย์ได้อย่างมีประสิทธิภาพ รูปแบบทางวิศวกรรมนี้ช่วยให้นักพัฒนาสามารถนำการเปลี่ยนแปลงไปใช้และแก้ไขความไม่ลงรอยกันได้อย่างรวดเร็วและมั่นใจ โดยไม่ต้องอาศัยรันไทม์เพื่อค้นหาจุดบกพร่องหรือกรณีความล้มเหลว โดยเฉพาะอย่างยิ่งไม่ต้องพึ่งพาผู้ใช้ในการสะดุดกับจุดบกพร่องด้วยตนเอง API การโยงถูกนำไปใช้กับคำอธิบายประกอบ Java ซึ่งช่วยให้คลาสใดๆ เชื่อมโยงกับสคีมา JSD(x) ที่มีประเภทที่รัดกุม แต่ในลักษณะที่มีน้ำหนักเบา ความสามารถในการผูกและการสร้างโค้ดที่พิมพ์อย่างเข้มงวดของ JSONx รองรับขอบเขตทั้งหมดของข้อกำหนด JSD(x) ซึ่งออกแบบมาโดยเฉพาะเพื่อให้ตรงตามมาตรฐานระดับสูงสำหรับโซลูชันระดับองค์กร

กรอบงาน JSONx ถูกสร้างขึ้นสำหรับโซลูชันระดับองค์กรและนำเสนอมาตรฐานคุณภาพและยูทิลิตี้ระดับสูงสำหรับระบบที่ซับซ้อน รวมถึงการตรวจสอบข้อผิดพลาดที่ง่ายต่อการใช้งานและเวลาในการแก้ไขสำหรับนักพัฒนา

เอ็นจิ้นการโยง JSD(x) ตัวประมวลผลและตัวตรวจสอบความถูกต้องรายงานความครอบคลุมการทดสอบ 87% ทำให้นักพัฒนา Java สามารถรวมกรอบงานได้อย่างมั่นใจเพื่อผูก JSD(x) schema กับแอปพลิเคชัน Java และเข้ารหัส ถอดรหัส และตรวจสอบเอกสาร JSON หากต้องการดู JSONx framework สำหรับ Java อย่างละเอียดยิ่งขึ้น โปรดดูที่ JSONx Framework สำหรับ Java

บทสรุป

เมื่อมองลึกลงไปถึงประวัติของเว็บและแนวโน้มของซอฟต์แวร์ในช่วงไม่กี่ปีที่ผ่านมา เราจะเห็นความสัมพันธ์ที่ใกล้ชิดระหว่างการเพิ่มจำนวน 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 ​​Schema คืออะไร? (W3C, ตุลาคม 2552)

4. อินเทอร์เน็ต: สารานุกรมประวัติศาสตร์ ลำดับเหตุการณ์ เล่ม 3, น. 130 (ABC-CLIO, 2005)

5. สคีมา JSON (กรกฎาคม 2551)

6. เครื่องมือตรวจสอบสคีมา JSON (GitHub)

7. JsonSchema และ SubClassing (Horne, มีนาคม 2016)