ถ้า XML แย่มาก ... ทำไมผู้คนมากมายถึงใช้มัน [ปิด]


37

ฉันเข้าใจวัตถุประสงค์ของ XML แต่ฉันมักจะได้ยินคนบ่นว่ามันแย่แค่ไหน? ฉันไม่เข้าใจว่ามันแย่ขนาดนั้นจริงเหรอ? ฉันมักจะได้ยินคำว่า "ป่อง" และ "ช้า" โยนไปรอบ ๆ

แต่ฉันคิดว่าในฐานะโปรแกรมเมอร์คุณจะใช้อะไรเป็นหลัก? และคุณคิดว่ามัน "แย่" จริง ๆ หรือไม่ .... เพราะถ้าเป็นเช่นนั้นมีผู้คนมากมายที่ใช้มันเพื่อส่งข้อมูล ...


1
คำตอบของคุณอยู่ในคำถาม ผู้คนยังคงใช้มันเพราะคนเคยใช้มันและตัวเลือกคือ (1) เขียนโค้ดทั้งหมดที่ใช้ก่อนหน้า JSON และ YAML หรือ (2) ดูดมันขึ้นมาและทำสิ่งที่โง่ ผู้คนจำนวนมากยังคงยืดอายุความรุนแรงเช่นกัน แต่นั่นไม่ได้พิสูจน์คุณค่าของการฝึกฝน
คู่ปรับ Shot

5
ลองใช้ JSON สำหรับเอกสารจริง (man page, Knuth, Hamlet, etc) คุณจะเข้าใจว่าทำไม XML จึงมีความสำคัญ นี่เป็นพื้นที่ที่ JSON ดูด (ไปข้างหน้าลอง) การใช้อันใดอันหนึ่งในพื้นที่การออกแบบของอีกฝ่ายนั้นเป็นที่น่าสงสัย ปัญหาจากการใช้ XML ในพื้นที่ของ JSON ส่วนใหญ่จะละเอียดและความเร็วในขณะที่ปัญหาจากการใช้ JSON ในพื้นที่ของ XML มีแนวโน้มที่จะเกี่ยวข้องกับการพกพา (พยายามที่จะทำงานร่วมกับเพื่อนที่ทำหนังสือใน JSON แต่เป็นวิธีของพวกเขาเอง) ปัญหาการตีความที่ต้องใช้ความพยายามของมนุษย์ในการแก้ไข ใช้เครื่องมือที่เหมาะสมสำหรับงานของคุณ
TextGeek

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

คำตอบ:


90

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

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


15
+1 - ทุกคนที่เคยจัดการกับ EDI เพียงแค่ปรารถนา XML ถูกประดิษฐ์ขึ้นก่อนที่ระเบียบจะเกิดขึ้น
Scott Whitlock

12
+1 ตรงกับความคิดของฉัน ฉันจะเพิ่มเฉพาะสำหรับการจัดเก็บข้อมูลธรรมดาและเรียบง่ายถึงแม้ว่ามันจะเป็นลำดับชั้น (แต่ไม่ลึกเกินไปที่ไม่เข้ากันกับอะไรเลย ) มีรูปแบบบางอย่างที่ทำงานได้ดีเช่นกัน - JSON และ YAML ที่โดดเด่นที่สุด หลังเป็นที่น่ากลัวเกี่ยวกับความสามารถในการอ่านของมนุษย์

11
ในการถอดความ jwz: "มีโปรแกรมเมอร์บางประเภทที่จะมองปัญหาและพูดว่า 'ฉันรู้ว่าฉันจะใช้ XML' ตอนนี้เขามีปัญหาสองข้อ "
Adam Crossland

13
ช่วยบอกฉันด้วยว่า OXML นั้นเป็นเรื่องตลกเหมือน Brainfuck หรือ Whitespace หรือ LOLCODE
dsimcha

9
@Shamim Hafiz, SOAP เป็นหนึ่งใน monstosities ที่เลวร้ายที่สุดที่เคยอบรมมาโดยมนุษยชาติ
SK-logic

24

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

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

ข้อเสียคือมันยากที่จะเขียนและเรียนรู้ได้ยากขึ้น ฉันยอมรับว่ามีการโต้แย้งที่จะทำให้เว็บไม่ต้องกลายเป็นเรื่องใหญ่อย่างรวดเร็วถ้า HTML นั้นเข้มงวดเหมือน XML แต่ฉันก็เถียงว่าเราจะดีใจถ้ามันทำในวันนี้ :)

นอกจากนี้อย่าใช้เพื่อทุกสิ่งเพียงเพราะคุณสามารถมีสติและวิจารณญาณในการนำไปใช้อย่างเหมาะสม หากสิ่งที่คุณมีคือ XML คุณมักจะเปลี่ยน XSLT จากสิ่งที่คุณต้องการ :)

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

ข้อดีของ XML

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

จุดด้อย

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

ใช้งานได้ดี

  • ไฟล์กำหนดค่า
  • รูปแบบการแลกเปลี่ยนข้อมูล
  • รูปแบบไฟล์ที่ยืดหยุ่น
  • การจัดเก็บเอกสารในฐานข้อมูล

การใช้งานไม่ค่อยดีนัก

  • รูปแบบการถ่ายโอนข้อมูล
  • การทำให้เป็นอันดับวัตถุ
  • การจัดเก็บข้อมูลเชิงสัมพันธ์ในฐานข้อมูล
  • รูปแบบไฟล์สำหรับสถานการณ์ I / O ประสิทธิภาพสูง

13
ฉันสงสัยว่า "ไฟล์การกำหนดค่า" ควรอยู่ภายใต้ "การใช้งานที่ดี" ไม่ใช่ข้อมูล แต่เป็นคำแนะนำ
daknøk

3
ฉันอยู่กับ @ daknøkที่นี่ - ฉันไม่สามารถนับจำนวนครั้งที่ฉันต้องใช้เวลาจำนวนมากในการหาข้อผิดพลาดในการกำหนดค่าในไฟล์ XML ยาวขนาดยาวที่ระบุบรรทัดการพึ่งพาการฉีดซึ่งขึ้นอยู่กับตัวพิมพ์เล็ก ๆ ตัวหนึ่ง แอตทริบิวต์ XML
Gjallar

3
หากข้อมูลไม่ดีขัดข้องแอปจะเป็นข้อมูลที่มีปัญหาหรือไม่
James Snell

4
รูปแบบไฟล์ใด ๆ ที่ผิดรูปแบบ / เสียหายมีโอกาสที่จะทำให้ซอฟต์แวร์เสียหาย ดังนั้น XML ไม่ใช่ผู้ร้ายที่นี่ ... เพียงแค่ใบสมัครของคุณ มิฉะนั้นโพสต์ที่ดี
Thomas Eding

3
คุณสามารถขยายใน "ครอบคลุมกรณีขอบจำนวนมากที่ YAML และ JSON ทำไม่ได้"
เทรเวอร์ Hickey

14

Jeff Atwood มีบล็อกโพสต์ที่ดีมากที่XML: The Angle Bracket Taxเกี่ยวกับเรื่องนี้ถ้าคุณต้องการให้แหล่งข้อมูลพูดถึงมัน

การใช้งานทั่วไปที่ฉันมีให้กับมันคือ:

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

  • ที่เก็บข้อมูลการกำหนดค่า Web.config และ app.config เป็นตัวอย่างทั่วไป แต่สคริปต์ nAnt ยังสามารถใช้ XML บางตัวได้เช่นกัน

ฉันไม่คิดว่ามันจะดีที่สุด แต่เพียงอย่างเดียวไม่ทำให้จิตใจของฉันแย่


11

เหตุผลสองประการ:

  1. มีโปรแกรมเมอร์ที่ไม่ดีออกมามากมาย XML อาจไม่ดี แต่ก็ง่าย (บนพื้นผิวอย่างน้อย) และทำให้ง่ายในการเขียนซอฟต์แวร์ที่ไม่ดี Sorta เช่น VB
  2. ผู้คนจำนวนมากในการตัดสินใจเหล่านี้ไม่ใช่โปรแกรมเมอร์ แต่ประเภทธุรกิจที่เคยได้ยินว่า "ทุกคนใช้ XML" และพวกเขาตัดสินใจว่าพวกเขาต้องการให้ผลิตภัณฑ์ของพวกเขาใช้ XML ด้วย

ช่างเป็นจุดที่ไร้สาระและไร้ประโยชน์อย่างสิ้นเชิง 1) XML อยู่ไกลจากความเลวและไม่มีอะไรเกี่ยวข้องกับคุณภาพของซอฟต์แวร์ที่คนเขียนไม่ว่าพวกเขาจะเลือกหรือไม่ฉันเคยเห็นโปรแกรมเมอร์ VB ที่ค่อนข้างดีซึ่งหมายความว่าถ้าคุณใช้ VB คุณเขียนซอฟต์แวร์ไม่ดีจริง ๆ คือ โง่เพียงเพราะมีการตัดการเชื่อมต่อที่สมบูรณ์ระหว่างวิธีการเขียนซอฟต์แวร์และสิ่งที่คุณใช้ในการเขียน 2) อีกข้อสมมติฐานที่ผิดพลาดการเลือก XML นั้นยอดเยี่ยมและคนส่วนใหญ่ที่เลือกให้ดีขึ้นหรือแย่ลงนั้นเป็นโปรแกรมเมอร์อย่างแน่นอน XML ไม่ใช่ bullet สีเงิน แต่มันก็ดีสำหรับบางสิ่ง
Eyal Solnik

2
@EalalSolnik: บางคนเมื่อมีปัญหาให้คิดว่า "ฉันรู้ว่าฉันจะใช้ XML"<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </ProblemWorsening>
Mason Wheeler

3
เพียงเพราะคนที่ทำผิดกฎเกี่ยวบางอย่างไม่ได้หมายความว่าเทคโนโลยีตัวเองไม่ดีคุณสามารถเห็นกลุ่มอาการเดียวกันในหลาย ๆ ที่
Eyal Solnik

8

ฉันมักจะได้ยินคำว่า "ป่อง" และ "ช้า" โยนไปรอบ ๆ

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

…ทำไมคนจำนวนมากถึงใช้มัน

มันแพร่หลาย คุณสามารถสืบค้นฐานข้อมูล XML ด้วย XQuery แปลงผลลัพธ์ด้วย XSLT เป็น XHTML หรือ Atom รับ Atom หรือรูปแบบ XML อื่น ๆ จากบริการเว็บอื่น ๆ รับ XML จากผู้ใช้โดยใช้ XForms ตรวจสอบกับ XMLSchema, Relax NG หรือ Schematron ประมวลผลด้วย XProc บันทึกกลับไปยังฐานข้อมูลด้วย XQuery Update เครื่องมือทั้งหมดเหล่านี้เข้าใจ XML ดังนั้นจึงไม่จำเป็นต้องทำแผนที่ระหว่างการนำเสนอที่แตกต่างกัน

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


... และเราถามตัวเองเป็นเวลาหลายปีว่าทำไม chrissakes SOAP จึงถูกสร้างขึ้นบน XML
JensG

6

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

XML นั้นไม่ได้เลวร้ายนัก แต่ฉันยอมรับว่าการออกแบบโซลูชัน "ดี" โดยใช้ XML นั้นไม่สำคัญ


5

"แก่นแท้ของ XML คือสิ่งนี้: ปัญหาที่แก้ไม่ยากและมันก็ไม่สามารถแก้ปัญหาได้ดี" - Phil Wadler, POPL 2003

ความคิดเห็นส่วนตัวของฉันคือตราบใดที่คุณไม่สนใจเกี่ยวกับการตรวจสอบ schemas, XSLTs และสิ่งที่น่าเกลียดที่เหลือและคุณรักษาขนาดของไฟล์ให้เล็ก (แยกวิเคราะห์ช้า) คุณสามารถใช้ XML (ตัวอย่าง) ใช้สำหรับกำหนดค่าแอปพลิเคชันของคุณแทนการใช้ไฟล์ INI)


4

จากประสบการณ์ของฉันคนส่วนใหญ่บ่นเกี่ยวกับวิธีการใช้งานไม่ใช่เทคโนโลยีเอง

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

ฉันใช้เพื่อเก็บข้อมูลที่มีโครงสร้างเล็กน้อยซึ่งฉันต้องการเก็บไว้ในดิสก์ (ไม่มีฐานข้อมูลหรือการทำให้เป็นเลขฐานสองแบบไบนารี่) หรือส่งผ่านไปยังแอปพลิเคชันอื่น (ซึ่งอธิบาย SOAP ด้วย)


2

มันดีเพราะ:

มันเป็น"ส่วนต่อประสาน"มาตรฐานที่ระบบหลายแบบสามารถใช้เพื่อสื่อสารกับมันได้ และเป็น "มนุษย์" ที่อ่านได้(ชนิดให้ลองจ้องที่ 5 MB XML)

มันแย่เพราะ:

ขนาดที่ใหญ่ขึ้น = แบนด์วิดท์มากขึ้น = มากขึ้น

มีเหตุผลอื่นทุกคนมีมือจับที่แตกต่างกัน ...


4
@Darknight: ฉันท้าทายมนุษย์ที่สามารถอ่านได้โดยการโยนหน่วยงาน Xml ที่คุณ ... (peeve ส่วนตัว)
Matthieu M.

1
ฉันไม่คิดว่า XML จะมีการปูดโดยเนื้อแท้ - แต่การใช้งานของมันคือ ฉันพบว่า XML-RPC มีความสำคัญอย่างยิ่งในการขยายตัวที่ไม่จำเป็น
HorusKol

3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>ข้อมูลอัตราส่วน / มาร์กอัปต่ำมาก ... ฉันเรียกสิ่งนี้ว่า "ป่อง" JSON advanceAcceptanceIndicator: "Y"ตัวอย่างเช่นจะเป็นเพียงครึ่งป่อง: นอกจากนี้ยังมีความจริงที่ว่าข้อความระหว่างแท็กนั้นถูกต้องดังนั้นเมื่ออ่าน Xml คุณต้องตัดสินใจว่าจะทำอย่างไรกับ cruft นี้\n\t\t\tและโดยทั่วไปการแก้ปัญหาก็แค่เพิกเฉยไปเพราะคุณไม่เคยสนใจเรื่องนี้มาก่อนเลย
Matthieu M.

1
@HorusKol: มัน แต่ฉันไม่เคยบอกว่ามันเป็นค่าบูลีนมันแค่เกิดขึ้นเป็น char เดียว :) การใช้คุณสมบัติที่นี่ ( value?) อาจจะดีกว่าด้วยเพราะคนอาจถูกล่อลวงเพื่อแทรกช่องว่างระหว่างสอง แท็ก
Matthieu M.

1
"ขนาดของมันที่ใหญ่ขึ้น = แบนด์วิดท์ที่มากกว่า = เพิ่มเติม $$" ฉันเดาว่าการบีบอัดยังไม่ได้ถูกคิดค้นขึ้นมาว่าคุณอยู่ที่ไหน
Andy

2

เช่นเดียวกับเทคโนโลยีอื่น ๆ : มีเครื่องมือและไลบรารีมากมาย

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

แต่:

  • สามารถระบุ Xml (xsd) และเครื่องมือที่มีอยู่ซึ่งตรวจสอบความสอดคล้องของข้อมูล Xml
  • เครื่องมือจำนวนมาก (โปรแกรมแก้ไขข้อความและอื่น ๆ ) รองรับ Xml
  • ไลบรารีจำนวนมาก (ในทุกภาษาการเขียนโปรแกรม) รองรับ Xml

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


5
XML สามารถอ่านได้มากกว่าข้อมูลไบนารีหรือตำแหน่ง - หรือคั่นด้วยเครื่องหมายจุลภาค
FrustratedWithFormsDesigner

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

1
@FrustratedWithFormsDesigner: มันขึ้นอยู่กับข้อมูลในมือ Xml ฝังลักษณะของข้อมูลใกล้กับข้อมูลที่เหมาะสม หากคุณดูภาษาโปรแกรมที่ใช้งานได้คุณจะเห็นสิ่งต่าง ๆ เช่น (Haskell): data Person = Person { surname :: String, firstName :: String, age :: Int }ถ้าฉันเห็นPerson "Doe" "John" 42มันสามารถอ่านได้เช่นกันและหลีกเลี่ยง cruft จำนวนมาก แต่ก็ใกล้กับเครื่องหมายจุลภาค
Matthieu M.

1
ตกลงตัวอย่างของคุณง่ายต่อการอ่านโดยไม่ต้องใช้มาร์กอัป แต่ตัวอย่างเล็กน้อย (ฉันจะบอกว่าน้อยกว่า 8 หรือ 9 องค์ประกอบข้อมูล) สามารถทำเพื่อสนับสนุนทุกรูปแบบ (ยกเว้นบางทีไบนารี) Datafeeds จากเมนเฟรมมาเป็นสตริงตำแหน่งคั่นด้วย (และส่วนใหญ่จะเป็นเพียงรหัสตัวเลข) และพวกเขามีมากง่ายต่อการอ่านและการแก้ปัญหาและจัดการหลังจากที่ถูกเปลี่ยนเพื่อ XML อย่างที่คุณพูดมันขึ้นอยู่กับ ...
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: ใช่นั่นคือจุดของฉัน :) มันขึ้นอยู่กับ แต่เนื่องจากมีระบบนิเวศที่อุดมไปด้วย XML และเนื่องจากง่ายต่อการบำรุงรักษาเครื่องมือ / ไลบรารีเพียงชุดเดียวผู้คนมักใช้ XML สำหรับทุกสิ่ง ส่วนตัวฉันชอบ JSon มากกว่า XML แต่อีกครั้งโดยไม่เยื้องมันยุ่ง: p
Matthieu M.

-1

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

สำหรับไฟล์ใด ๆ ที่ต้องดูแลรักษาโดยมนุษย์ฉันต้องการใช้ JSON, YAML หรือซอร์สโค้ดในภาษาที่แปลบางภาษา (Python, Ruby, Groovy และอื่น ๆ ) เราพบว่าวิธีที่ยอดเยี่ยมในการสร้างการกำหนดค่า XML สำหรับรหัสดั้งเดิมคือการใช้ Groovy MarkupBuilder อีกทางเลือกที่ดีคือการสร้างภาษาเฉพาะโดเมน นี่เป็นเรื่องง่ายที่จะทำกับ Ruby, Groovy และภาษาอื่น ๆ อีกมากมาย


8
ฉันคิดว่าคุณขาดจุดของ XML มาร์กอัปคือเนื้อหา วัตถุประสงค์ของ XML คือเพื่ออธิบายความหมายของข้อมูลของคุณ ตัวอย่างเช่นหากคุณมีหมายเลขโทรศัพท์การติดแท็กเป็นหมายเลขโทรศัพท์พื้นฐานหรือ mobilenumber จะเพิ่มบริบทที่ผู้อื่นอาจใช้ หรือเพิ่มแท็กโทรศัพท์รอบข้อความสำหรับทุกเรื่อง (อาจทำให้หมายเลขนั้นสามารถโทรได้บนโทรศัพท์มือถือ) สำหรับประเด็นอื่น ๆ ของคุณฉันไม่เห็นด้วยเช่นกัน การเขียนเอกสาร xml นั้นค่อนข้างตรงไปตรงมา ข้อความผิดพลาดจะเกี่ยวข้องเสมอ wellformedness และฉันจะใช้ XML การแก้ไขด้วยมือมากกว่า JSON วันใด
Homde

@konrad ตัวอย่างโทรศัพท์ของคุณจะใช้ได้กับ HTML
Florian F

"ข้อผิดพลาดใด ๆ ในเอกสาร XML นั้นร้ายแรง แต่เอกสาร XML ไม่สามารถประมวลผลได้บางส่วน" ใช่นั่นเป็นเรื่องใหญ่ไปจนถึงจุดของ XML
Andy

@Andy มันค่อนข้างไร้ประโยชน์ถ้า XML นั้นถูกเขียนขึ้นโดยมนุษย์และแอปพลิเคชันก็บอกว่า "ผิด!" โปรแกรมแก้ไขมนุษย์จำเป็นต้องรู้บรรทัดที่ตรวจพบข้อผิดพลาด
วินไคลน์

เครื่องมือจำนวนหนึ่งจะบอกคุณอย่างชัดเจนว่าบรรทัดใดและบ่อยครั้งที่ตรวจพบข้อผิดพลาดอักขระ ตัวอย่างเครื่องมือ XML ใน NotePad ++ . Net จะบอกคุณว่าไฟล์. config ของคุณตรงกับที่ใด หากคุณกำลังพูดถึง API ข้อดีอย่างหนึ่งของ XML คือผู้พัฒนา API ยังสามารถให้ XSD ได้ซึ่งนอกจากจะทำให้แน่ใจว่าไวยากรณ์ XML ที่ถูกต้องนั้นยังสามารถบอกคุณได้ว่าคุณมีองค์ประกอบใดที่ไม่ได้อยู่ในนั้นหรือไม่ เป็นเพียงหนึ่งในองค์ประกอบนั้น ๆ json ที่เขียนด้วยลายมือนั้นง่ายกว่าที่จะพลาด
แอนดี้

-2

การแยกวิเคราะห์ค่อนข้างง่ายในขณะที่มนุษย์อ่านได้ในเวลาเดียวกัน

และ parsers ที่ดี (เช่น Xerces {c ++}) ก็พร้อมใช้งาน


2
ง่ายนิดเดียวถ้าเอกสารมีขนาดเล็ก หากคุณต้องแยกเอกสารที่มีขนาดใหญ่เกินไปให้พอดีกับหน่วยความจำพอสมควรสิ่งต่าง ๆ ก็น่ากลัว
TMN

ฉันจะถามส่วนการอ่านของมนุษย์ ใช้ความพยายามมากเกินไปในการอ่าน XML ผ่านการอ่าน JSON ที่เทียบเท่า
cmaster
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.