10 คะแนน โดย GN⁺ 2025-06-04 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบจัดพิมพ์สมัยใหม่ ที่ขยายไวยากรณ์ Markdown แบบเดิม เพื่อให้สร้างเอกสารได้ง่ายในหลายรูปแบบ เช่น หนังสือ งานวิจัย สไลด์ และงานนำเสนอ
  • ฝังความสามารถขั้นสูงอย่าง การรองรับฟังก์ชัน การใช้ตัวแปร เงื่อนไข/ลูป และไลบรารีมาตรฐาน ลงใน Markdown โดยตรง ทำให้มีจุดเด่นด้าน ความสามารถในการขยายและระบบอัตโนมัติ เหนือกว่า Markdown แบบเดิมหรือ LaTeX
  • ใช้ไฟล์ต้นฉบับเพียงไฟล์เดียวเพื่อสร้างผลลัพธ์ได้หลายแบบ เช่น HTML, PDF, สไลด์(reveal.js), paged book(paged.js) จึงเหมาะกับการสร้างคอนเทนต์แบบอิงโค้ด
  • ด้วย ความสามารถด้านสคริปต์ และ ไวยากรณ์ส่วนขยายที่แสดงออกได้ยืดหยุ่น จึงสามารถสร้างคอนเทนต์ที่ซับซ้อนหรือมีความเป็นไดนามิกได้อย่างอิสระ
  • มีสภาพแวดล้อมแบบ REPL, live preview และการคอมไพล์ที่รวดเร็ว ช่วยให้แก้ไขและดีบักเอกสารได้แบบเรียลไทม์
  • เมื่อเทียบกับเครื่องมือเดิม ๆ มีข้อได้เปรียบเหนือ Markdown, LaTeX, Typst, AsciiDoc, MDX ในด้าน ความสามารถด้านสคริปต์ การควบคุมเอกสาร และเส้นโค้งการเรียนรู้ที่ไม่ชัน
  • ใช้งานได้บนระบบปฏิบัติการหลักทั้งหมด โดยไม่ต้องมีสภาพแวดล้อมพัฒนาแยกต่างหากหรือการตั้งค่าซับซ้อน ขอเพียงมี Java 17 ขึ้นไป

About

  • Quarkdown คือระบบจัดพิมพ์สมัยใหม่ที่เพิ่มฟังก์ชันและไวยากรณ์ส่วนขยายลงบนโครงสร้างพื้นฐานของ Markdown เพื่อให้ผู้ใช้สร้างผลงานคุณภาพสูงได้ง่าย ตั้งแต่ข้อความธรรมดาไปจนถึง หนังสือ งานวิจัย และสไลด์ ในหลายรูปแบบ
  • พัฒนาบนพื้นฐานของ CommonMark และ GFM และรองรับทั้งไวยากรณ์เฉพาะ ฟังก์ชัน ตัวแปร ไปจนถึงไลบรารีที่ผู้ใช้กำหนดเอง
    • มีไวยากรณ์เฉพาะชื่อ Quarkdown Flavor
    • เพิ่มความสามารถขั้นสูงอย่างฟังก์ชัน เงื่อนไข และลูปให้กับ Markdown ผ่าน ไวยากรณ์ส่วนขยายฟังก์ชันที่ Turing-complete
  • ใช้งานความสามารถหลากหลายได้ผ่านไลบรารี .qmd เช่น เลย์เอาต์ อินพุต/เอาต์พุต คณิตศาสตร์ เงื่อนไข และลูป
  • แม้เป็นเอกสารที่มีโครงสร้างซับซ้อนหรือคอนเทนต์แบบไดนามิก ก็ยังช่วยเพิ่มทั้งความสามารถในการขยายและประสิทธิภาพการทำงานได้

คุณสมบัติหลักและการใช้งาน

  • รองรับฟอร์แมตผลลัพธ์หลากหลาย เช่น HTML, สไลด์, หนังสือ(Paged), PDF
    • สามารถกำหนดประเภทเอกสารได้ด้วยการเรียกฟังก์ชันอย่าง .doctype {slides}, .doctype {paged}
    • ทำงานร่วมกับเอนจินโอเพนซอร์สอย่าง reveal.js และ paged.js
  • การเขียนสคริปต์และคอนเทนต์แบบไดนามิก
    • นำองค์ประกอบเชิงโปรแกรมมาใช้ เช่น ฟังก์ชัน ตัวแปร เงื่อนไข และลูป
    • เช่น .function {greet} ... .greet {world} from:{iamgio}
  • live preview และการคอมไพล์ที่รวดเร็ว
    • มีการแสดงตัวอย่างแบบเรียลไทม์และความสามารถตรวจจับการเปลี่ยนแปลงไฟล์ (Watch)
    • เพิ่มประสิทธิภาพการทำงานด้วยออปชัน -p --preview, -w --watch
  • เปรียบเทียบกับเครื่องมือเอกสารอื่น
    • เรียนรู้ง่ายกว่า LaTeX และขยายความสามารถได้ดีกว่า Markdown
    • เมื่อเทียบกับ Typst, AsciiDoc, MDX ก็ยังเด่นกว่าในด้านสคริปต์และพลังการแสดงออก

เป้าหมายที่รองรับ

  • HTML
    • เอาต์พุตทั่วไป (ค่าเริ่มต้น)
    • สไลด์ (ใช้ reveal.js)
    • รูปแบบหนังสือ/งานวิจัย (ใช้ paged.js, ต้องมีเว็บเซิร์ฟเวอร์)
  • PDF
    • สามารถส่งออกเป็น PDF ได้โดยคงประเภทเอกสารและความสามารถทั้งหมดที่ HTML รองรับ
    • ดูรายละเอียดเพิ่มเติมเกี่ยวกับการส่งออก PDF ได้ที่ wiki เอกสาร
  • ควบคุมฟอร์แมตเอาต์พุตได้ด้วยการเรียกฟังก์ชันอย่าง .doctype {slides}, .doctype {paged}

การเปรียบเทียบ

Quarkdown Markdown LaTeX Typst AsciiDoc MDX
ความกระชับ·ความอ่านง่าย
การควบคุมเอกสารทั้งชุด
ความสามารถด้านสคริปต์ รองรับบางส่วน
เอาต์พุตรูปแบบหนังสือ/บทความ 3rd party
เอาต์พุตแบบงานนำเสนอ 3rd party
เส้นโค้งการเรียนรู้ เขียว เขียว แดง ส้ม เขียว เขียว
เป้าหมายที่รองรับ HTML, PDF HTML PDF, PostScript PDF HTML, PDF, ePub HTML

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

 
plastic041 2025-06-05

น่าจะเป็นเพราะมีตาราง เลย์เอาต์บนมือถือเลยพังครับ

 
plastic041 2025-06-05

ให้ .topic_contents มี min-width: 0 ก็แก้ได้แล้วครับ min-width นี่ชวนปวดหัวจริง ๆ...

 
xguru 2025-06-05

อ๋อ ผมแก้ปัญหาได้ด้วยวิธีอื่นแล้วครับ ขอบคุณมาก!

 
plastic041 2025-06-05

ขอบคุณสำหรับฟีดแบ็กที่รวดเร็วครับ~

 
GN⁺ 2025-06-04
ความคิดเห็นบน Hacker News
  • KeenWrite โปรแกรมแก้ไขข้อความ FOSS ของฉัน ใช้วิธีคล้ายกันในการแปลง Markdown เป็น XHTML, TeX และ PDF
    สถาปัตยกรรมซอฟต์แวร์แสดงให้เห็นว่าสามารถออกแบบ processor chain ได้อย่างไร
    เหตุผลที่ฉันสร้าง KeenWrite ก็เพื่อให้ใช้ตัวแปรอย่างชื่อของตัวละครหรือสถานที่ได้ตอนเขียนนิยายวิทยาศาสตร์
    ดูรายละเอียดได้ในบทแนะนำ
    สำหรับคนที่ยังใช้ pandoc และ shell script อยู่ ซีรีส์ Typesetting Markdown ชุดนี้ อธิบายวิธีสร้างอินฟราสตรักเจอร์แบบสคริปต์สำหรับแปลง Markdown เป็น PDF
    ข้อมูลเกี่ยวกับ KeenWrite เองดูได้ที่นี่
    และดูแผนภาพสถาปัตยกรรมได้ที่นี่

  • น่าสนใจถ้าจะลองเปรียบเทียบโปรเจ็กต์นี้กับ Typst ที่ช่วงนี้ได้รับความสนใจมาก แต่ก็น่าแปลกที่ในเมทริกซ์เปรียบเทียบฟีเจอร์กลับไม่พูดถึง Typst เลย

    • ตอนที่ฉันเคยดู Typst ยังส่งออกเป็น HTML ไม่ได้
    • ตอนนี้มีการพูดถึง Typst แล้ว
      โดยรวมแล้วสองโปรเจ็กต์นี้ดูคล้ายกันมาก
  • สงสัยว่าตารางเปรียบเทียบนี้แม่นยำไหม – ลิงก์
    ฉันคิดว่า LaTeX มีความสามารถด้านสคริปต์ครบถ้วนแน่นอน ถึงแม้มันจะใช้งานทรมานก็ตาม
    ฉันค่อนข้างสงสัยกับคำกล่าวที่ว่าไวยากรณ์อันพิสดารของ Quarkdown กระชับและอ่านง่ายกว่า Typst
    เส้นโค้งการเรียนรู้ก็คงไม่ได้ง่ายกว่า Typst ด้วย ทั้งสองอย่างดูแทบไม่ต่างกัน
    และฉันคิดว่า LaTeX ก็สร้าง HTML ได้ผ่าน tex4ht

    • พูดตามตรง Markdown ส่วนใหญ่ก็ใช้ใน Quarkdown ได้ตรง ๆ
      กำแพงเริ่มต้นคงต่ำไปกว่านี้ไม่ได้แล้ว
      แน่นอนว่าเส้นโค้งการเรียนรู้ไม่ใช่คำเดียวกับกำแพงเริ่มต้น แต่ทั้งสองอย่างก็ทับซ้อนกันมาก
      และ "เส้นโค้งการเรียนรู้" ก็เป็นคุณสมบัติที่ค่อนข้าง主観
      ถ้าใส่ลงในตารางเปรียบเทียบก็บิดเบือนตั้งแต่ต้นแล้ว
      ฟีเจอร์ที่ชัดเจนนั้นเป็นกลางกว่า แต่บางครั้งตามลักษณะของผลิตภัณฑ์ก็อาจไม่จำเป็นต้องมีฟีเจอร์บางอย่าง
    • สำหรับ use case แบบนี้ Pandoc ดีที่สุด
    • แค่ดู TikZ กับ pgf ก็พอจะเข้าใจได้ทันทีว่าความสามารถด้านสคริปต์ของ LaTeX และ TeX ไปได้ไกลแค่ไหน
      ตารางเปรียบเทียบนี้ผิดอย่างชัดเจน
  • ตัวอย่างผลลัพธ์ดูสวยมาก
    แต่โดยส่วนตัวฉันไม่ค่อยชอบเวลาภาษาเทมเพลตค่อย ๆ โตไปเป็นการเรียกฟังก์ชันหรือความซับซ้อนมากนัก
    แน่นอนว่าในบริบทนี้มันอาจมีเหตุผล
    แต่ถ้าต้องใช้ร่วมกับภาษาอื่น เช่น การเรนเดอร์ฝั่งเซิร์ฟเวอร์หรือการสร้างเอกสารจากข้อมูล ก็จะเสียเวลาไปกับการสลับไปมาระหว่างสองภาษา
    ภาษาเทมเพลตไม่มีวันทรงพลังเท่าภาษา "จริง"
    เพราะอย่างนั้นฉันเลยชอบแนวทางแบบ JSX หรือ tagged template literal ของ JavaScript มากกว่า
    ถ้าใช้ภาษาโปรแกรมจริงและยังเข้าใจบริบทของเอกสารได้ด้วย ก็จะลดความกังวลเรื่องการ escape (อย่าง XSS) ได้ดีกว่า

  • สงสัยว่าโปรเจ็กต์นี้ต่างจาก Quarto อย่างไร
    ชื่อก็คล้ายกัน นามสกุลไฟล์ก็เหมือนกัน และทิศทางก็ดูใกล้เคียงกัน แต่ฟีเจอร์กลับดูน้อยกว่า – Quarto

    • Quarto คือผู้สืบทอดโดยพฤตินัยของ ecosystem ฝั่ง R Markdown
      ใน FAQ ก็ระบุว่าเป็นผู้พัฒนาชุดเดียวกัน
    • ฉันก็กำลังจะถามเหมือนกัน
      เมื่อไม่กี่วันก่อนเพื่อนฉันโชว์ให้ดูว่าเขาเขียนสคริปต์การสอนทั้งหมดใหม่ด้วย Quarto แล้วฝัง presentation เข้าไปด้วย ดูค่อนข้างเรียบร้อยดี
      การที่ Quarto ทำงานร่วมกับ R Studio และ Jupyter Notebook ได้ดี ก็เป็นข้อได้เปรียบใหญ่
    • ที่ชื่อคล้ายกันน่าจะมาจากการอ้างอิงหรือเชื่อมโยงกับ QuarkXPress
      ฉันคิดว่านี่เป็นปรากฏการณ์แบบวิวัฒนาการลู่เข้า
  • คำอธิบายที่ว่าสิ่งที่ดูเหมือน "planet" จริง ๆ แล้วคือ quark โดยเฉพาะ down quark นั้นน่าสนใจดี
    เป็นโปรเจ็กต์ที่เท่มาก แต่เพราะ QuarkXPress เป็นแบรนด์ดังในวงการสิ่งพิมพ์ การใช้คำว่า 'Quark' เป็นชื่อระบบจัดพิมพ์ก็ดูเสี่ยงนิดหน่อย
    ดูข้อมูลการจดทะเบียนเครื่องหมายการค้าได้ที่นี่, ที่นี่
    (ก็สงสัยเหมือนกันว่าทำไมถึงจดทะเบียนคำเดียวกันไว้สองรายการ)

  • ทุกกระทู้ถกเถียงในสายนี้มักจะมีคอมเมนต์แนว "ทำไมไม่ใช้ LaTeX ล่ะ?" อยู่ราว 70% ดังนั้นขอพูดให้ชัดก่อนเลยว่า
    ฉันต้องการระบบจัดพิมพ์สมัยใหม่ที่อิงกับ Markdown จริง ๆ
    อยากให้มีความพยายามหลายแบบในการมาแทน LaTeX
    LaTeX ใช้งานลำบากและเป็นแนวทางแบบเก่ามาก ถ้ามีระบบที่ให้มาร์กอัปได้อิสระกว่านี้ก็คงดี
    ต่อให้ฟีเจอร์เยอะขึ้นจนไวยากรณ์ยาวขึ้นบ้าง ก็ยังมีพื้นที่สำหรับสิ่งที่ทรงพลังมากกว่า Markdown เล็กน้อยอยู่แน่นอน
    แต่โปรเจ็กต์นี้ดูไม่ใช่สิ่งที่ฉันตามหา
    จากตัวอย่างมันเหมือนจะเอนเอียงไปทาง "ทรงพลังมากกว่า Markdown นิดหน่อย" มากกว่า และยังไม่ถึงขั้นแทน LaTeX (หรือ Typst) ได้เต็มตัว
    ระบบเอกสารประเภทนี้ต้องใช้งานได้ "ลื่นมากจริง ๆ" แต่ตัวนี้ยังไม่ให้ความรู้สึกแบบนั้น

    1. แถมยังอยู่บน JVM ด้วย ฉันเลยไม่อยากแม้แต่จะติดตั้ง
      สำหรับการแพร่หลายแล้ว นี่ไม่ใช่ภาพลักษณ์ที่ดีนัก
    2. ฉันก็ไม่ชอบไวยากรณ์ด้วย
      อยากให้เข้ากันได้กับ Markdown ปกติให้มากที่สุด แต่การที่ต้องเยื้องสำหรับอาร์กิวเมนต์ของฟังก์ชันดูเหมือนจะทำให้ทั้งเอกสารต้องถูกเยื้องตามไปด้วย ขณะที่จุดขยายของ Markdown ปกติมักใช้ code block (````plugin-name` แบบนั้น) ซึ่งดูเป็นธรรมชาติกว่า
      และความต่างของไวยากรณ์อาจบังคับให้ต้องเปลี่ยนโครงสร้างทั้งเอกสาร
    3. คอนเซปต์ "Markdown ที่ดีกว่า" ฉันว่ามันเหมาะกับกรณีที่เริ่มจากโน้ตส่วนตัวแล้วค่อย ๆ เติบโตเป็นเอกสารสาธารณะมากกว่า
      ถ้าตั้งใจจะทำเอกสารเพื่อการตีพิมพ์ตั้งแต่แรก ก็ทำใน LaTeX ไปเลยก็ได้
      มันจะมีประโยชน์ที่สุดเมื่อผสานเข้ากับแอปจดโน้ตได้ดี
      บางคนอาจใช้ใน Emacs หรือ Vim แต่ในฐานะคนสายย้อนยุค ฉันก็ต้องยอมรับว่าสุดท้ายตัวเองก็ย้ายมาใช้ Obsidian และอย่างอื่นเหมือนกัน
      ถ้ามีส่วนที่ช่วยควบคุมโครงสร้างเอกสารจากในแอปจดโน้ตได้ดีขึ้น หรือเชื่อมกับความสามารถด้านการเผยแพร่ได้ ก็น่าจะดี
      ถ้าเป็นแอปแยกเดี่ยวก็ยังสงสัยว่าทำไมต้องใช้
      อย่างน้อย Typst ก็ยังมีตัวแก้ไขออนไลน์ ซึ่งทุกคนก็ดูจะใช้กันแบบนั้น
    • LaTeX ไม่ใช่ของเก่าห่วย ๆ แต่มันคือหนึ่งในซอฟต์แวร์ที่ดีที่สุด
      หัวใจสำคัญคือมันไม่ยัดสิ่งไร้สาระลงไปในเอกสาร
  • ระบบแบบนี้ (รวม Typst ด้วย) โดยพื้นฐานแล้วมีไว้สำหรับการจัดพิมพ์ข้อความยาวอย่างงานวิชาการ
    ฉันอยากให้มันเป็นทางเลือกแทน HTML ได้ แต่พอลองใช้ Typst ก็ยังรู้สึกว่าผู้เขียนสนใจแทบจะเฉพาะ "งานวิชาการหรือเอกสารยาว"
    ฉันอยากทำพวกแบบฟอร์ม ใบแจ้งหนี้ ใบปลิว นามบัตร อะไรแบบนี้ด้วย แต่ดูเหมือนองค์ประกอบเหล่านี้ไม่อยู่ในความสนใจ
    (จริง ๆ ฉันนึกถึง Sile แต่ Typst ก็คล้ายกัน)
    ฉันไม่ได้ใช้ Typst ลึกมากเพราะมันมีส่วนเชิงพาณิชย์

    • ฉันไม่แน่ใจว่ามีเหตุผลพิเศษอะไรที่ทำให้ใช้ Typst กับสิ่งอย่างแบบฟอร์ม ใบแจ้งหนี้ ฯลฯ ไม่ได้
      โดยเฉพาะแบบฟอร์มแบบ interactive นั้นก็มีข่าวว่ากำลังทำอยู่แล้ว (backend ของ pdf writer รองรับบางส่วนแล้วด้วย)
      อีกไม่นาน Typst ก็น่าจะมีฟีเจอร์แบบฟอร์ม – ดูissue
    • ฉันคิดว่านั่นเพราะมันใกล้กับ "งานกราฟิกดีไซน์" มากกว่า "การจัดพิมพ์"
      ของอย่างใบแจ้งหนี้ โบรชัวร์ หรือนามบัตร ต้องวางองค์ประกอบเล็ก ๆ ให้ตรงกลางหน้า หรือชิดขอบอย่างแม่นยำ ซึ่งเครื่องมือแบบ WYSIWYG สะดวกกว่า
      ถ้าพึ่งการจัดพิมพ์แบบข้อความล้วนจะต้องลองผิดลองถูกมากเกินไป
      ตัวอย่างเช่นแท็บลอยด์อาจต้องให้ข้อความไหลและโอบล้อมรูปหรือคัตเอาต์ที่ไม่ใช่สี่เหลี่ยม ซึ่งถ้าไม่เห็นด้วยตาตัวเองแล้วทำแค่ด้วยพิกัดจะยากมาก
    • ตัวแก้ไขออนไลน์ของ Typst เป็นเชิงพาณิชย์ก็จริง แต่ตัว Typst เองเปิดเผยภายใต้Apache 2.0 license
      ฉันติดตั้งผ่าน cargo ของ Rust และใช้งานได้สบายโดยไม่ต้องพึ่งตัวแก้ไขออนไลน์
    • จะใช้ Typst แบบโลคัลก็ได้ แล้วข้ามส่วนเชิงพาณิชย์ไปเลย
      มันค่อนข้างง่ายสำหรับการสร้างเอกสารหลายประเภท
      ฉันใช้มันแทนของเดิมสำหรับทำสไลด์และเอกสารแจกแล้ว
    • งาน "ใช้งานจริง" ชิ้นแรกของฉันใน Typst คือโปสเตอร์ และมันง่ายกว่า LaTeX มาก
      ถึงจะยังไม่มีฟีเจอร์บางอย่างอย่าง image wrapping หรือ text flow แต่สิ่งเหล่านี้ก็ยากใน TeX เหมือนกัน และ Typst ก็มีแผนจะเพิ่มในอนาคต
      ตัวอย่างโปสเตอร์
  • นี่ดูแทบจะเหมือน reStructuredText (rST) เลย
    ไวยากรณ์ฟังก์ชันของ Quarkdown (.somefunction {อาร์กิวเมนต์} {อาร์กิวเมนต์} body) คล้ายมากกับไวยากรณ์ฟังก์ชันของ rST (.. somefunction:: {อาร์กิวเมนต์} {อาร์กิวเมนต์} body)

  • มีทั้ง Markdown, Quarkdown, Typst และอีกมากมายจนดูไม่เป็นมาตรฐาน สุดท้ายเลยย้อนกลับไปใช้ HTML+CSS

    • แล้ว XML ล่ะ?
      ฉันยังไม่เคยใช้ตรง ๆ แต่กำลังคิดอย่างจริงจังอยู่เหมือนกัน
      ฟอร์แมตอื่น ๆ ที่เหลือล้วนซับซ้อนและมีเส้นโค้งการเรียนรู้ จนรบกวนการเขียนเสียเปล่า
      แต่ XML ให้ฉันกำหนดแท็กเองได้ จะสร้างโครงสร้างแบบต่าง ๆ ผ่าน parser เช่น การสร้างเชิงอรรถอัตโนมัติก็ได้
      สงสัยว่ามีใครเคยใช้แนวทางแบบนี้บ้างไหม
    • Markdown ในระดับพื้นฐานนั้นมีประสิทธิภาพมากจริง ๆ
      ปัญหาคือมีคนจำนวนมากชอบเอาระบบมาซ้อนทับเพิ่มทันที แล้วพยายามแก้ปัญหาอะไรที่ "ซับซ้อนกว่าเดิม" ตั้งแต่แรก
      พวกเขาคิดว่ากำลังปรับปรุงระบบที่เดิมตั้งใจให้เรียบง่าย แต่จริง ๆ แล้วกลับไม่เข้าใจข้อจำกัดของมัน และยิ่งเพิ่มความซ้ำซ้อนกับความสับสนโดยไม่จำเป็น
      ปัญหาไม่ใช่ว่าฟีเจอร์ไม่พอ แต่เป็นการเอาไปใช้นอกขอบเขตที่ออกแบบไว้
      ต่อให้ Windows notepad มีการจัดรูปแบบเพิ่มเข้ามา ฉันก็ยังไม่คิดว่านั่นเป็นการปรับปรุงในเชิงแก่นแท้
      เพราะ notepad เดิมทีมีหน้าที่ของมันอยู่แล้ว
    • ยังมี Org-mode ที่โตเต็มที่และเชื่อถือได้ด้วย
      ถ้าไม่รังเกียจ Emacs มันก็เป็นตัวเลือกที่ดี
    • ฉันเองก็รู้สึกว่าการใช้ HTML, CSS, Javascript ไปเลย แล้วจัดการ DOM ในงานเว็บนั้นสนุกกว่า
      ไม่ต้องจำเฟรมเวิร์กเป็นร้อยหรือไวยากรณ์ซับซ้อนขนาดนั้น
      แค่สั่ง AI ให้สร้างตัวแปลง markdown to html ก็ยังโอเค
    • ถ้าในปี 2005 โปรแกรมแก้ไขข้อความมีระบบ autocomplete ที่รองรับการบาลานซ์แท็ก การเยื้อง และไฮไลต์ได้ดีแบบทุกวันนี้ บางทีฟอร์แมตอย่าง JSON, YAML, Markdown อาจไม่ได้ดังขนาดนี้ก็ได้
      ใน The Art of Unix Programming ที่ออกปี 2003 ก็มีพูดไว้ว่าการแก้ XML ตรง ๆ นั้นทรมาน เลยต้องสร้างฟอร์แมตและ parser ใหม่กันมากมาย