XML มักถูกใช้ในทางที่ผิดเกือบทุกครั้ง

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

ไม่ใช่เรื่องเกินจริงที่จะบอกว่า XML Schema ส่วนใหญ่ที่ฉันเคยเห็นนั้นเป็นการใช้ XML ที่ไม่เหมาะสมหรือไม่ถูกต้อง นอกจากนี้ การใช้ XML นี้แสดงให้เห็นถึงความเข้าใจผิดขั้นพื้นฐานว่า XML คืออะไร

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

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

จากมุมมองนี้ มีวิธีง่ายๆ ในการตรวจสอบว่า XML Schema ถูกสร้างขึ้นมาได้ดีเพียงใด มาดูตัวอย่างเอกสารในสคีมาที่ต้องการและลบแท็กและแอตทริบิวต์ทั้งหมดออกจากเอกสาร หากสิ่งที่เหลืออยู่ไม่สมเหตุสมผล (หรือหากยังมีบรรทัดว่างเหลืออยู่) แสดงว่าสคีมาของคุณไม่ได้ถูกสร้างขึ้นอย่างถูกต้อง หรือคุณไม่ควรใช้ XML

ด้านล่างนี้ฉันจะยกตัวอย่างวงจรที่สร้างขึ้นอย่างไม่ถูกต้องที่พบบ่อยที่สุด

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

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

<root name="John" city="London" />

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

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

นี่คือสิ่งที่ดีกว่า แต่ตอนนี้ด้วยเหตุผลบางอย่าง คีย์คือข้อมูลเมตาและค่าไม่ใช่ การดูพจนานุกรมที่แปลกมาก หากคุณลบแท็กและแอตทริบิวต์ทั้งหมด ข้อมูลครึ่งหนึ่งจะหายไป

นิพจน์พจนานุกรมที่ถูกต้องใน XML จะมีลักษณะดังนี้:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

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

สคีมา XML ที่แย่ที่สุด? โดยวิธีการรับรางวัลสำหรับ สคีมา XML ที่แย่ที่สุดที่ฉันเคยเห็น รับรูปแบบไฟล์การกำหนดค่าการจัดเตรียมอัตโนมัติสำหรับโทรศัพท์ระบบโทรศัพท์ Polycom IP ไฟล์ดังกล่าวจำเป็นต้องดาวน์โหลดไฟล์คำขอ XML ผ่าน TFTP ซึ่ง... โดยทั่วไป นี่คือข้อความที่ตัดตอนมาจากไฟล์ดังกล่าว:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

นี่ไม่ใช่เรื่องตลกที่ไม่ดีของใครบางคน และนี่ไม่ใช่สิ่งประดิษฐ์ของฉัน:

• องค์ประกอบถูกใช้เป็นคำนำหน้าเพื่อแนบแอตทริบิวต์ซึ่งมีชื่อแบบลำดับชั้น
• หากคุณต้องการกำหนดค่าให้กับบันทึกประเภทใดประเภทหนึ่งหลายอินสแตนซ์ คุณต้องใช้ชื่อแอตทริบิวต์ในการดำเนินการนี้ ซึ่งมีดัชนี.
• นอกจากนี้คุณสมบัติที่ขึ้นต้นด้วย softkey.จะต้องวางไว้บนองค์ประกอบ <softkey/>, คุณลักษณะที่เริ่มต้นด้วย feature.จะต้องวางไว้บนองค์ประกอบ <feature/> ฯลฯ แม้ว่าจะดูไม่จำเป็นเลยและเมื่อมองแวบแรกก็ไม่มีความหมายก็ตาม
• และสุดท้าย หากคุณหวังว่าองค์ประกอบแรกของชื่อแอตทริบิวต์จะเหมือนกับชื่อองค์ประกอบเสมอ - ไม่มีอะไรแบบนั้น! ตัวอย่างเช่น คุณลักษณะ up. จะต้องแนบไปกับ <userpreferences/>. ลำดับการแนบชื่อแอตทริบิวต์กับองค์ประกอบนั้นเป็นไปตามอำเภอใจ เกือบจะสมบูรณ์

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

แนวคิดของความแตกต่างระหว่าง เอกสารและข้อมูล. ในฐานะที่เป็นอะนาล็อกของ XML เราสามารถนำเอกสารที่เครื่องอ่านได้ตามเงื่อนไข แม้ว่าตั้งใจให้เครื่องอ่านได้ แต่ก็อ้างอิงถึงเอกสารในเชิงเปรียบเทียบ และจากมุมมองนี้จริงๆ แล้วเทียบได้กับเอกสาร PDF ซึ่งส่วนใหญ่มักไม่สามารถอ่านด้วยเครื่องได้

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

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

กล่าวอีกนัยหนึ่ง พจนานุกรม (ชิ้นส่วนของข้อมูลที่มีโครงสร้าง) สามารถแปลงเป็นได้ n เอกสารต่างๆ ที่เป็นไปได้ (ในรูปแบบ XML, PDF, กระดาษ ฯลฯ ) โดยที่ n - จำนวนการรวมกันขององค์ประกอบที่เป็นไปได้ในพจนานุกรมและเรายังไม่ได้คำนึงถึงตัวแปรที่เป็นไปได้อื่น ๆ

อย่างไรก็ตาม ยังตามมาด้วยว่าหากคุณต้องการถ่ายโอนเฉพาะข้อมูล การใช้เอกสารที่เครื่องอ่านได้จะไม่เกิดผล มันใช้โมเดลซึ่งในกรณีนี้มันไม่จำเป็นแต่จะขวางทางเท่านั้น นอกจากนี้ ในการดึงข้อมูลต้นฉบับ คุณจะต้องเขียนโปรแกรม แทบจะไม่มีประโยชน์เลยในการใช้ XML สำหรับบางสิ่งที่จะไม่ได้รับการจัดรูปแบบเป็นเอกสาร ณ จุดใดจุดหนึ่ง (เช่น การใช้ CSS หรือ XSLT หรือทั้งสองอย่าง) เนื่องจากนั่นคือเหตุผลหลัก (หากไม่ใช่เท่านั้น) ในการทำเช่นนี้ สู่โมเดลเอกสาร

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

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

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

ในปัจจุบัน XML schema เดียวที่ฉันรู้ว่าฉันสามารถเรียกการใช้รูปแบบที่ถูกต้องได้อย่างแท้จริงคือ XHTML และ DocBook

ที่มา: will.com