เมื่อ "ไม่ได้คิดค้นที่นี่" สมเหตุสมผล: เหตุใด Tritium ถึงสร้าง DOCX Engine แบบกำหนดเอง

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

ปัญหา Round-Trip ที่ทำให้โซลูชันที่มีอยู่ใช้การไม่ได้

ฟังก์ชันหลักของ Tritium เกี่ยวข้องกับการแก้ไขเอกสารทางกฎหมายที่ซับซ้อนอย่างละเอียด โดยยังคงรักษาทุกองค์ประกอบของการจัดรูปแบบเดิมไว้ ซึ่งต้องการสิ่งที่นักพัฒนาระบุว่าเป็น round-trip ที่สมบูรณ์แบบ – ความสามารถในการอ่านเอกสาร Word และเขียนกลับโดยไม่สูญเสียข้อมูลใดๆ เลย แม้แต่จากองค์ประกอบที่ซอฟต์แวร์ไม่เข้าใจอย่างถ่องแท้ คราเต docx_rs ที่มีอยู่ แม้จะยอดเยี่ยมสำหรับการสร้างเอกสารใหม่ แต่ก็ต่อสู้กับข้อกำหนดนี้เนื่องจากแนวทางการแยกวิเคราะห์โครงสร้าง DOCX ที่ใช้ enum เป็นพื้นฐาน

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

ฉันสงสัยว่าทำไม round-trip ถึงเป็นความกังวลที่เล็กน้อยสำหรับผู้คนที่นำเครื่องมือซีเรียลไลซ์/ดีซีเรียลไลซ์ประเภทต่างๆ ไปใช้

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

ความท้าทายทางเทคนิคหลักในการประมวลผล DOCX

• การซ้อนกันแบบไม่มีที่สิ้นสุด: ข้อกำหนดของ Word อนุญาตให้มีตารางภายในย่อหน้าภายในตาราง ซึ่งสร้างโครงสร้างแบบเรียกซ้ำที่ซับซ้อน
• การจัดการหน่วยความจำ: เอกสารทางกฎหมายสามารถมี XML entities มากกว่า 100,000 รายการ ซึ่งต้องการการจัดเก็บข้อมูลที่มีประสิทธิภาพ
• ความสมบูรณ์ของข้อกำหนด: ข้อกำหนดของ Word มีขนาดใหญ่มากและมีการพัฒนาอยู่ตลอดเวลา
• การรองรับแพลตฟอร์ม: จำเป็นต้องทำงานได้ทั้งบนแอปพลิเคชันดั้งเดิมและบนเว็บ (สภาพแวดล้อม WASM)

การแลกเปลี่ยนระหว่างหน่วยความจำกับความสมบูรณ์

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

สมาชิกในชุมชนแนะนำโซลูชันที่เป็นไปได้ เช่น string interning (เก็บแท็กที่ซ้ำกันเป็นข้อมูลอ้างอิงเพื่อประหยัดหน่วยความจำ) หรือการใช้งานตัวแปรที่ไม่รู้จักแบบ catch-all อย่างไรก็ตาม ดังที่ทีม Tritium ตอบกลับมา โซลูชันที่ดีกว่าในระยะยาวคือการนำส่วนต่างๆ ของข้อกำหนด Word ขนาดมหึมามาใช้งานให้มากขึ้น เมื่อคุณครอบคลุมแท็กประมาณ 80% แล้ว คุณก็น่าจะแก้ไขปัญหาเรื่องหน่วยความจำได้ 99.9% เมื่อพิจารณาว่าการใช้งานแท็กเป็นไปตามการกระจายแบบ power-law

การเปรียบเทียบแนวทางการประมวลผล DOCX

บริบททางประวัติศาสตร์และโซลูชันสมัยใหม่

การอภิปรายได้เปลี่ยนไปในทางประวัติศาสตร์ที่น่าสนใจ เมื่อผู้แสดงความคิดเห็นระบุว่ารูปแบบดั้งเดิมของ Word นั้นโดยพื้นฐานแล้วคือการดัมพ์ข้อมูลส่วนหนึ่งของส่วนข้อมูลของกระบวนการ Word โดยตรง แนวทางที่ใช้ memory-mapped นี้เร็วมากแต่สร้างความฝันร้ายเรื่องการพกพาข้ามระบบและเวอร์ชัน Word ที่ต่างกัน ดังที่ผู้แสดงความคิดเห็นหนึ่งคนอธิบาย มีความกังวลเรื่องการพกพาที่ชัดเจน: little-endian กับ big endian, 32-bit กับ 64-bit, struct padding ฯลฯ

โซลูชันสมัยใหม่เช่น Cap'n Proto และ FlatBuffers ได้ฟื้นฟูแนวคิดนี้ด้วยการสนับสนุนข้ามแพลตฟอร์มที่ดีขึ้น แต่สำหรับรูปแบบไฟล์เพื่อการทำงานผลิตภาพ ฉันทามติมักจะโน้มเอียงไปทาง explicit serialization เพื่อความเสถียรและความสามารถในการกู้คืนที่ดีกว่า การย้ายไปใช้ไฟล์ DOCX ที่ใช้ XML ทำให้การกู้คืนเอกสารมีความน่าเชื่อถือมากกว่าฟอร์แมตไบนารีแบบเก่าอย่างมาก

กรณีทางธุรกิจสำหรับการเป็นเจ้าของสแต็กของคุณ

ส่วนที่เปิดเผยที่สุดของการอภิปรายอาจอยู่ที่การถกเถียงว่า Tritium ควรเปิดเผย源代码โซลูชันของพวกเขาหรือไม่ ทีมงานยอมรับความเป็นไปได้แต่แสดงความกังวลว่าการทำให้มันเป็นแบบทั่วไปเกินไปจะทำให้มันกลายเป็น LibreOffice รุ่นที่ด้อยกว่าในที่สุด โมเดลธุรกิจของพวกเขามุ่งเน้นไปการให้ผลิตภัณฑ์เฉพาะทางกฎหมายนี้ฟรีแก่ชุมชน ในขณะที่เรียกเก็บเงินจากผู้ใช้เชิงพาณิชย์ที่ต้องการคุณสมบัติขั้นสูง

แนวทางนี้สะท้อนถึงความเข้าใจที่ละเอียดอ่อนของ Joel Spolsky เกี่ยวกับ In Defense of Not-Invented-Here Syndrome แบบคลาสสิก – เมื่อบางสิ่งเป็นแกนหลักของธุรกิจของคุณ คุณจำเป็นต้องเป็นเจ้าของมัน ดังที่สมาชิกชุมชนหนึ่งคนสังเกต: ยากที่จะเชื่อว่าทนายความได้อยู่โดยปราศจากสิ่งนี้มาเป็นเวลานาน ซึ่งเน้นย้ำถึงช่องเฉพาะที่ Tritium เข้าไปเติมเต็ม

การเดินทางจากการใช้ docx_rs ไปสู่การสร้างโซลูชันแบบกำหนดเองนั้นแสดงให้เห็นถึงความจริงพื้นฐานในการพัฒนาซอฟต์แวร์: บางครั้งการตัดสินใจทางวิศวกรรมที่ดีที่สุดเกี่ยวข้องกับการสร้างสิ่งที่คนอื่นอาจมองว่ามีคนแก้ไขแล้ว สำหรับ Tritium ข้อกำหนดเรื่องความเที่ยงตรงของเอกสารที่สมบูรณ์แบบในบริบททางกฎหมาย ทำให้การลงทุนในการเป็นเจ้าของสแต็ก DOCX ของพวกเขาสมเหตุสมผล พิสูจน์ให้เห็นว่าในโดเมนเฉพาะทาง ไม่ได้คิดค้นที่นี่ อาจเป็นเส้นทางที่เชื่อถือได้ที่สุดที่จะก้าวไปข้างหน้า

อ้างอิง: Thoughts on the Word Spec in Rust