XML คือ DSL ราคาถูก

 (unplannedobsolescence.com)
10 คะแนน โดย GN⁺ 2026-03-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรมสรรพากรสหรัฐฯ เปิดซอร์ส Tax Withholding Estimator(TWE) รุ่นใหม่ โดยมีหลักการออกแบบสำคัญคือ โครงสร้างที่จำลองกฎหมายภาษีสหรัฐฯ ด้วยสเปกเชิงประกาศบน XML
  • ลอจิกการคำนวณภาษีของ TWE สร้างอยู่บนเอนจินลอจิกชื่อ Fact Graph และแสดงรายการภาษีแต่ละส่วนเป็นกราฟความพึ่งพาของ “fact” ที่นิยามด้วย XML
  • หากใช้ ภาษาเชิงคำสั่ง อย่าง JavaScript เพื่อเขียนลอจิกภาษี จะเกิดปัญหาอย่างการจัดการลำดับการทำงาน การสูญหายของค่ากลาง และการเปิดเผยรายละเอียดการติดตั้งใช้งาน จึงจำเป็นต้องใช้แนวทางเชิงประกาศ
  • JSON ไม่เหมาะกับการจัดการนิพจน์ซ้อนกันได้ตามอำเภอใจ ขณะที่ XML มีแท็กที่บอกชนิดของอ็อบเจ็กต์ได้ในตัว จึง เหมาะกว่ามากสำหรับการสร้าง DSL
  • XML ยังใช้ประโยชน์จาก ระบบนิเวศของเครื่องมือที่เติบโตเต็มที่ อย่าง XPath ได้ฟรี จึงเป็นตัวเลือกที่คุ้มค่าที่สุดสำหรับสเปกเชิงประกาศข้ามแพลตฟอร์ม

Fact Graph: กฎหมายภาษีสหรัฐฯ ที่เขียนด้วย XML

  • Tax Withholding Estimator(TWE) ที่ IRS เผยแพร่ เป็นเครื่องมือให้ผู้เสียภาษี กรอกรายได้และยอดหักลดหย่อนเพื่อประเมินภาษีและยอดหัก ณ ที่จ่าย
    • โครงการนี้เผยแพร่เป็น โอเพนซอร์ส และเปิดให้บุคคลทั่วไปมีส่วนร่วมได้
  • TWE เป็นเว็บแบบสแตติกที่สร้างจาก การตั้งค่า XML สองชุด โดยชุดแรกคือ Fact Dictionary ที่ใช้อธิบายกฎหมายภาษีสหรัฐฯ
  • Fact Graph คือเอนจินลอจิกที่เดิมสร้างขึ้นในโครงการ IRS Direct File และใช้คำนวณภาระภาษีกับยอดหัก ณ ที่จ่ายของผู้เสียภาษีโดยอิงกับ fact ที่นิยามไว้ใน Fact Dictionary
  • fact แต่ละรายการถูกนิยามด้วย XML เช่น /totalOwed ถูกแสดงเป็น fact แบบอนุพันธ์ (Derived) ที่นำ /totalTax มาลบ /totalPayments
    • “ยอดค้างชำระทั้งหมด (total owed)” คือผลต่างระหว่างภาษีรวมตามรายได้ (total tax) กับจำนวนเงินที่ชำระไปแล้ว (total payments)
  • refundable credits คือเครดิตภาษีที่ทำให้ยอดภาษีติดลบได้ เช่น Earned Income Credit, Child Tax Credit, American Opportunity Credit ซึ่งถูกรวมด้วย <Add>
  • non-refundable credits ลดภาระภาษีได้ถึงแค่ 0 โดยใช้ตัวดำเนินการ <GreaterOf> เพื่อเลือกค่าที่มากกว่าระหว่าง 0 กับ (ภาษีชั่วคราว - non-refundable credits)
  • ค่าที่ผู้ใช้ป้อนใช้แท็ก <Writable> แทน <Derived> และกำหนดชนิดค่าด้วย <Dollar/>, <Boolean/> เป็นต้น
  • fact ต่าง ๆ พึ่งพากันและสร้างเป็น โครงสร้างกราฟ ที่นำไปสู่ตัวเลขภาษีสุดท้าย

ทำไมลอจิกภาษีจึงต้องใช้สเปกเชิงประกาศ

  • หากเขียนการคำนวณเดียวกันด้วย JavaScript อาจดูสั้นอย่าง const totalOwed = totalTax - totalPayments แต่แนวทางนี้เป็นแบบ เชิงคำสั่ง (imperative) ที่ทำงานตามลำดับและทำให้ค่าระหว่างทางหายไปหลังรัน
  • เมื่อความสัมพันธ์การพึ่งพาซับซ้อนขึ้น จะเกิด ปัญหาลำดับการทำงาน: ฟังก์ชันรับอินพุตผู้ใช้อย่าง getInput() สามารถบล็อกการคำนวณทั้งหมดที่ตามมา และคำถามที่ต้องถามก็ต้องเปลี่ยนไปตามปัจจัยอย่างการมีคู่สมรส
  • ในลอจิกการรวมรายได้ Social Security รายละเอียดการติดตั้งใช้งานของ JavaScript อย่าง map/reduce ถูกเปิดเผยออกมา แต่ <CollectionSum> ใน XML แสดง แนวคิดทางคณิตศาสตร์ของภาษีโดยตรง
    • ใช้ <Dependency path="/socialSecuritySources/*/totalFederalTaxesPaid"/> เพื่อรวมค่ารายการภายในคอลเลกชัน
  • Fact Dictionary เป็นแนวทาง เชิงประกาศ (declarative) โดยไม่ต้องระบุขั้นตอนหรือคำสั่งทำงานอย่างละเอียด เพียงระบุการคำนวณที่มีชื่อและความสัมพันธ์การพึ่งพา แล้วเอนจินจะตัดสินใจวิธีรันเอง
  • ข้อดีสำคัญที่สุดของโมเดลภาษีเชิงประกาศคือ ความสามารถในการตรวจสอบย้อนหลัง (auditability) และ การตรวจสอบภายใน (introspection): สามารถถามโปรแกรมได้ว่า “ตัวเลขนี้ได้มาอย่างไร”
    • โปรแกรมเชิงคำสั่งทิ้งค่ากลางไปแล้ว จึงตรวจได้แค่ผ่านล็อกหรือดีบักเกอร์ และเมื่อมีกระบวนการคำนวณกลางหลายร้อยขั้นแบบกฎหมายภาษีสหรัฐฯ ก็ขยายต่อไม่ได้
  • ตามคำกล่าวของ Chris Given ผู้เขียนดั้งเดิมของ Fact Graph มันคือ “วิธีการ พิสูจน์ ว่ารายการที่ไม่ได้ถูกถามไม่ได้เปลี่ยนผลการยื่นภาษี และผู้ใช้ได้รับสิทธิประโยชน์ทางภาษีที่มีสิทธิครบถ้วน”
  • Intuit ผู้สร้าง TurboTax ก็ได้ข้อสรุปเดียวกันและเผยแพร่เอกสาร “Tax Knowledge Graph” ในปี 2020 แต่การติดตั้งใช้งานยังไม่เปิดเผย
    • ส่วน IRS Fact Graph เป็น โอเพนซอร์สและสาธารณสมบัติ ที่ใครก็ศึกษา แบ่งปัน และต่อยอดได้

ทำไม XML ถึงเหมาะกับ DSL มากกว่า JSON

  • หากลองใช้ JSON เป็นรูปแบบแทนข้อมูลเชิงประกาศของกฎหมายภาษี จะพบว่า การจัดการนิพจน์ซ้อนกันได้อย่างอิสระนั้นยุ่งยากมาก
    • เพราะโครงสร้างข้อมูลเชิงประกอบเพียงอย่างเดียวของ JSON คืออ็อบเจ็กต์ ดังนั้นอ็อบเจ็กต์ลูกทุกตัวต้องระบุชนิดของตัวเองด้วย "type", "kind" เป็นต้น
    • ใน XML ชื่อแท็กก็คือชนิดของอ็อบเจ็กต์ อยู่แล้ว จึงไม่ต้องประกาศเพิ่ม
  • แม้แต่การแทน fact /tentativeTaxNetNonRefundableCredits ในรูปแบบ JSON ก็ยังยาวและซับซ้อนกว่า XML
  • XML รองรับ คอมเมนต์ (comment) และจัดการช่องว่าง/ขึ้นบรรทัดใหม่ได้อย่างสมเหตุสมผล โดยไม่มีข้ออึดอัดที่มักพบใน JSON
  • attribute และ named children ให้ความสามารถในการออกแบบภาษีที่ เลือกได้ว่าจะเน้นอะไร
  • สามารถนิยาม ชนิดข้อมูลเฉพาะทาง ได้ เช่น การแยก “ดอลลาร์” ออกจาก “จำนวนเต็ม”
  • เมื่อต้องจัดการข้อความอธิบายยาว ๆ XML อ่านและแก้ไขด้วยมือได้สบายกว่า JSON มาก

ความเป็นสากลและระบบนิเวศเครื่องมือของ XML

  • ไวยากรณ์ทางเลือกอย่าง S-expression, Prolog, KDL อาจอ่านง่ายกว่า XML แต่การใช้ XML ทำให้ได้ parser และระบบนิเวศเครื่องมืออเนกประสงค์มาใช้ฟรี
    • S-expression ทำงานได้ดีใน Lisp, Prolog term ทำงานได้ดีใน Prolog แต่ XML แปลงไปเป็นรูปแบบใดก็ได้
  • ใน Prolog การแปลง XML เป็น Prolog term ทำได้ด้วย predicate เดียว
  • ยังมีการกล่าวถึงคำถามจากผู้ใช้ Hacker News ชื่อ ok123456 ที่ถามว่า “ทำไมไม่ใช้ Prolog/Datalog” ซึ่งแม้จะทำได้ แต่ XML เหนือกว่าในแง่ความเป็นสากล
  • Chris Given กล่าวถึง YAML ว่า “อย่าพยายามเขียนลอจิกกฎหมายภาษีสหรัฐฯ ด้วย YAML เด็ดขาด”
  • ตัวอย่างการใช้ XPath จริง: เขียนสคริปต์ด้วยคำสั่งเชลล์บรรทัดเดียวเพื่อค้นหา fact path แบบฟัซซี และเปิดดูคำนิยามของ path ที่เลือกได้ทันที
    • cat facts.xml | xpath -q -e '//Fact/@path' | grep -o '/[^"]*' | fzf เพื่อค้นหา fact
    • ยังเพิ่มความสามารถในการไล่ย้อน dependency chain เพื่อดูว่า fact ไหนพึ่งพา fact นั้นอยู่บ้าง
    • จาก bash script ราว 60 บรรทัด มันพัฒนากลายเป็นเครื่องมือดีบักที่ใช้แทบทุกวัน
  • สมาชิกทีมคนอื่นก็สร้าง เครื่องมือดีบักด่วน แบบคล้ายกันของตัวเอง โดยแค่พาร์ส XML เล็กน้อยและทำงานในภาษาที่ถนัด โดยไม่ต้องไปแตะ implementation ของ Fact Graph ที่เขียนด้วย Scala
  • บทเรียนสำคัญคือ รูปแบบการแทนข้อมูลอเนกประสงค์มีคุณค่ามาก และในหมวดนี้มีเพียง JSON กับ XML
    • ในกรณีส่วนใหญ่ควรเลือก JSON แต่ถ้าต้องการ DSL XML คือทางเลือกที่ถูกที่สุด และความคุ้มค่านี้ทำให้ทีมเอางบด้านนวัตกรรมไปใช้กับเรื่องอื่นได้

ข้อมูลเพิ่มเติม

  • แม้คนที่ไม่ใช่โปรแกรมเมอร์ก็อ่าน XML ได้ หากออกแบบสคีมามาดี แต่ก็ควร สร้างมุมมองทางเลือกแยกต่างหาก ด้วย
  • ช่วงหลังความสนใจต่อ XML เพิ่มขึ้น เช่น grex เครื่องมือของ Jake Low ที่แปลงเอกสาร XML เป็นรูปแบบแบนตามบรรทัด และ Xee ของ Martijn Faassen ซึ่งเป็น เอนจิน XPath/XSLT สมัยใหม่ที่เขียนด้วย Rust
  • fact ของ TWE มีไว้สำหรับประเมินการหักภาษี ณ ที่จ่าย จึง ไม่ควรนำไปใช้กับการยื่นภาษีโดยตรง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-15
ความคิดเห็นจาก Hacker News

  • XML เป็น ฟอร์แมตที่แพง หากต้องการพาร์สให้ถูกต้องในหลายภาษา
    ในทางปฏิบัติ ถ้าจะทำให้ใกล้เคียงมาตรฐานจริง ๆ ก็ต้องพึ่ง implementation โอเพนซอร์สอย่าง libxml2, expat, และ Xerces
    แก่นของภาษาตระกูล SGML คือการมอง “ลิสต์” เป็นวัตถุชั้นหนึ่ง และการซ้อนเป็นวัตถุชั้นสอง พร้อมทั้งเพิ่มเมทาดาทาได้ผ่านสองแกนคือชื่อแท็กและแอตทริบิวต์
    XML ยังมีประโยชน์ในฐานะ DSL แต่ถ้าจะใช้ XML จริง ๆ ก็ควรเลิกใช้คำว่า “cheap”
    อีกอย่างคือสามารถทำให้ declarative DSL ดูเหมือนนิพจน์เชิง imperative ได้ด้วย ตัวอย่างเช่นนิพจน์อย่าง totalOwed = totalTax - totalPayments อาจมีความหมายเทียบเท่ากับ XML DSL
    ภาษาตัวอย่างอย่าง METAFONT แสดงแนวทางนี้ไว้ (ลิงก์ตัวอย่าง)

    • มักจะเห็น XML ทำพลาดแบบเดิมซ้ำ ๆ
      หลายคนลืมความจริงง่าย ๆ ว่า ยิ่งใส่ฟีเจอร์ลงในฟอร์แมตมากเท่าไร ก็ยิ่งพาร์สยากขึ้นเท่านั้น
      เหตุผลที่ JSON ได้รับความนิยมก็เพราะมีฟีเจอร์น้อยจึงพาร์สง่าย
      ในทางกลับกัน XML ใส่ทั้ง attributes, namespaces, CDATA, DTDs และอื่น ๆ มากเกินไป
      เคยมีการคุยกันว่าจะใช้ SQLite เป็นฟอร์แมตแลกเปลี่ยนข้อมูล แต่ก็เสี่ยงจะซับซ้อนแบบ XML เหมือนกัน
      นี่ก็เป็นเหตุผลที่ CSV ยังได้รับความนิยมเพราะมันเรียบง่าย
      ความพยายามสมัยนี้ที่จะยัดคอมเมนต์หรือข้อมูลชนิดลงใน JSON คือการ เอาคุณสมบัติแย่ ๆ ของ XML กลับมาสร้างใหม่

    • ในฐานะคนเขียนบทความ ฉันเห็นด้วย
      การทำให้สเปกเชิงประกาศดูเหมือนสมการคณิตศาสตร์นั้นทำได้ แต่สุดท้ายมันก็คือ การสร้างภาษาใหม่
      เมื่อเป็นแบบนั้นก็จะมีปัญหาว่าต้องพอร์ต parser ไปทุก environment
      เรื่องอย่าง operator precedence หรือไวยากรณ์แบบ switch expression ก็ต้องตัดสินใจเองทั้งหมด และสุดท้ายความซับซ้อนจะพุ่งขึ้นมาก
      นี่จึงเป็นเหตุผลที่ใช้คำว่า “cheap” — การเลือกใช้ฟอร์แมตที่มี parser และ tooling อยู่แล้วในทุก environment ช่วยลดต้นทุนได้จริง
      แม้ความสามารถในการแสดงออกจะลดลง แต่สำหรับ ทีมขนาดเล็ก นี่เป็นทางเลือกที่ฉลาด

    • เคยใช้ XML เยอะมากในโลก enterprise Java และมันเป็น ตัวการหลักของคอขวดด้านหน่วยความจำและ CPU
      XML ไม่มีทาง cheap เลย

    • หัวใจของ SGML คือ content model แบบ regular-expression ของ element
      มันไม่ได้มีแค่โครงสร้างแบบลิสต์ แต่ยังนิยามกฎการสร้างไวยากรณ์แบบ BNF ได้ด้วย

    • การบอกว่าไม่ใช่ “XML proper” แต่เป็น “XML lookalike” ฟังดูจุกจิกเกินไป
      ถึงจะไม่ได้ใช้ทุกฟีเจอร์ของ XML มันก็ยังเป็น XML อยู่ดี
      ก็เหมือนเรียกรถโรงเรียนที่ไม่มีที่วางแก้วว่า “รถที่ทำตัวเหมือนรถบัส”

  • คิดว่าแทนที่จะใช้ XML ก็ควรใช้ ภาษาที่รองรับ eDSL ได้ดี
    ภาษาอย่าง Haskell, OCaml, Scala สามารถแสดงการคำนวณแบบขนานได้ง่ายด้วยแนวคิดอย่าง applicative หรือ arrow
    ใน JavaScript เองก็ทำ abstraction อย่าง sum แทน .reduce() ได้
    ถ้าจะสร้าง XML DSL สุดท้ายก็ต้องกลับมาแก้ปัญหาเดิมเรื่อง parallelization, readability และ การประดิษฐ์ไวยากรณ์ใหม่
    ในโดเมนที่ซับซ้อนมีโอกาสสูงที่จะชนกับกฎข้อที่ 10 ของ Greenspun

    • แต่ภาษาพวก Haskell ก็มีปัญหาว่าเรียนรู้ยาก
      แม้แต่นักพัฒนาที่มีประสบการณ์ 30 ปีก็ยังรู้สึกว่ากำแพงการเข้าถึงสูง

    • Raku ก็เป็นตัวเลือกที่ดี
      เริ่มต้นจากพื้นฐาน Haskell และรองรับ Grammar ในตัวกับสไตล์ functional จึงเหมาะกับการเขียน DSL

    • HTML! (มุกสั้น ๆ)

    • Lisp ก็ทำได้
      พอเห็น S-expression แล้วจะรู้ทันทีว่า XML เยิ่นเย้อและเทอะทะ แค่ไหน

  • โครงสร้าง JSON สามารถออกแบบให้ดีกว่านี้ได้
    ถ้าให้แต่ละโหนดประกอบด้วย type key หนึ่งตัวกับค่าแบบอาร์เรย์ ก็จะเขียนแทนแบบ S-expression ได้
    วิธีนี้ทำให้ พาร์สแบบสตรีมมิง ได้และรู้ชนิดข้อมูลได้ก่อน
    มีประโยชน์กับชุดข้อมูลขนาดใหญ่

    • JSON เรียบง่ายกว่า XML มากและ ต้นทุนในการพาร์สต่ำกว่า
      XML ต้องจัดการสถานะที่ซับซ้อน เช่น การจับคู่แท็กและการจัดการแอตทริบิวต์
      แต่ JSON แค่จับคู่ {}, [] ให้ถูกก็พอ
      ความเรียบง่ายนี้สะสมกลายเป็น latency ที่ลดลง

    • แต่ JSON มีเครื่องหมายอัญประกาศเยอะเกินไปจนให้ความรู้สึกเป็น visual noise
      ส่วนตัวคิดว่า EDN ของ Clojure ดูสะอาดกว่ามาก

    • โครงสร้าง JSON แบบนี้ให้ความรู้สึกว่าเป็นรูปแบบที่ เสื่อมถอยลงในเชิงสุนทรียะ
      ถ้าข้อมูลต้องการแท็ก ก็ควรใช้รูปแบบการแทนที่เหมาะกับมันมากกว่า

  • บทความ The Lost Art of XML น่าสนใจกว่า
    มุมมองที่ว่าเครื่องมือเว็บดีเวลอปเมนต์จำนวนมากเกิดขึ้นเพราะ XML แพ้ในสงครามเบราว์เซอร์ นั้นน่าประทับใจ

    • แต่ข้ออ้างที่ว่า “XML ถูกทิ้งเพราะ JavaScript ชนะ” นั้นเห็นด้วยยาก
      เดิมทีเบราว์เซอร์ก็รองรับ XML อยู่แล้ว (X ใน AJAX ก็คือ XML)
      แค่นักพัฒนาไม่ชอบ XML เท่านั้นเอง
      คิดว่า XML ถูกเมินเพราะ ออกแบบเกินความจำเป็นและซับซ้อนเกินไป

    • ในฐานะคนที่ผ่านยุค XML API มาเอง ต้องบอกว่า XML ทรมานมาก
      แต่ละภาษาต้องทำ encoder/decoder แยกกัน และการดูแลรักษาก็ยาก
      JSON แมปกับแค่อาร์เรย์และอ็อบเจ็กต์ จึง เข้ากันได้ข้ามภาษาอย่างยอดเยี่ยม
      พอนึกถึงสมัยที่เสียเวลาไปกับประชุมออกแบบ XML schema แล้ว JSON ก็เหมือน Prettier ที่ยุติศึกแท็บ vs สเปซ ในการออกแบบ API

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

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

  • ฉันใช้งาน DSL ที่อิง S-expression อยู่โดยตรง
    มันทำหน้าที่แทน HTML และ CSS ใน desktop browser runtime ที่อิง WebAssembly
    และยังนำกลับมาใช้กับภาษามาร์กอัปเฉพาะของตัวเองเพื่อแก้ปัญหาการซิงก์เอกสารด้วย
    ตัวอย่างที่เกี่ยวข้องดูได้จากโค้ดตัวอย่าง CanvasUI, ไฟล์สไตล์, และ เครื่องมือทำเอกสาร

    • S-expression มีข้อดีคือ เขียน parser ได้ง่ายมาก จนเคยเอาไปใช้เป็นโจทย์สัมภาษณ์
      ปฏิกิริยาตอนที่ผู้สมัครสามารถสร้างภาษาง่าย ๆ ขึ้นมาเองได้นั้นน่าประทับใจมาก

  • XML ไม่ได้เป็น DSL เท่าไรนัก แต่เป็น เครื่องมือ parser/lexer แบบทั่วไป มากกว่า
    มันแค่แปลงข้อความเป็น AST ส่วน DSL ที่แท้จริงคือสเปกที่นิยามอยู่บนมัน
    แม้จะมีฟีเจอร์เยอะและซับซ้อน แต่ข้อดีคือ มี ecosystem ของ tooling ที่อุดมสมบูรณ์
    เหมาะกับการประมวลผลข้อความที่ถูกสร้างขึ้นมากกว่าการเขียนด้วยมือ

  • การตรวจสอบ schema ด้วย XSD มีมาให้ในตัว จึงสามารถ เช็กความสอดคล้องของเอกสารได้ทันที
    การบ่นว่า XML ยากทั้งที่ไม่ได้ใช้เครื่องมืออัตโนมัติ ก็เหมือนจัดการไบนารีโดยไม่มี disassembler

    • แต่การตรวจ schema เพียงอย่างเดียวก็ไม่ได้รับประกัน ความถูกต้องของเนื้อหา
      เหมือนกับที่ type checking ไม่ได้การันตีความถูกต้องของโปรแกรมทั้งหมด

    • XSD มีประโยชน์ แต่ก็ซับซ้อนและมีข้อจำกัดมาก
      ด้วยเหตุนี้ชุมชน XML บางส่วนจึงย้ายไปใช้ RELAX-NG แต่ก็ไม่สามารถมาแทนทั้งหมดได้

    • สงสัยว่างานแบบไหนกันที่จำเป็นต้องพึ่งการตรวจ XSD จริง ๆ

  • XML ในฐานะภาษามาร์กอัปนั้นโอเค และใช้เป็นฟอร์แมตแลกเปลี่ยนข้อมูลก็พอได้ แต่ถ้าเอามาเป็น ภาษาโปรแกรมจะเลวร้ายมาก
    JSON ก็คล้ายกัน คือดีสำหรับการแลกเปลี่ยนข้อมูล แต่ถ้าใช้เป็นภาษาก็มักจะจบไม่สวย
    ภาษาที่อิง YAML อย่าง Ansible คือหนึ่งในตัวอย่าง
    ในทางกลับกัน S-expression ของ Lisp มีโครงสร้างคล้าย JSON แต่กลับพัฒนาเป็น ภาษาที่ยอดเยี่ยม ได้

  • ปัญหาของ XML ไม่ได้อยู่ที่ตัว XML เองเท่าไร แต่อยู่ที่ การสร้าง XML ที่ดีทำได้ยาก
    มาตรฐานซับซ้อน และผู้ผลิตแต่ละรายก็แทนข้อมูลกันคนละแบบจนขาดความสม่ำเสมอ
    JSON มีความแปรปรวนแบบนี้น้อยกว่ามาก
    แค่เห็น XML จากสถาบันการเงินก็แทบสิ้นหวังแล้ว

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

    • ที่จริงปัญหาไม่ใช่เรื่อง “XML ที่ดี” แต่เป็นเรื่องที่มันเปิดทางให้สร้าง “XML แย่ ๆ” ได้ง่ายเกินไป
      เพราะแบบนั้นชุมชนจึงพยายามสร้าง interoperability ผ่าน namespaces, validation, transformations, semantic web และอื่น ๆ
      มันคือการประนีประนอมเพื่อให้ยังทำงานต่อไปได้ในโลกที่ไม่มีทางได้ฉันทามติสมบูรณ์