Document-based computing รุ่นล่าสุดอย่าง "OpenDoc" จึงถูกออกแบบมาให้มีลักษณะเป็นกลางสามารถใช้ได้กับโปรแกรมประยุกต์จากเหล่าบริษัทผู้ผลิตได้อย่างไม่จำกัดยี่ห้อ (vendor-neutral) ซึ่งน่าจะเป็นมาตรฐานระบบเปิด (open standard) สำหรับรูปแบบของเอกสาร Compound document ในอนาคต ที่สามารถประกอบไปด้วยข้อมูลทุกประเภท ไม่ว่าจะเป็น ตาราง, แผนผัง, กราฟ, ตัวอักษร, หรือจนกระทั่งสัญญาณวิดีโอ, สัญญาณเสียง, โน็ตการ์ด และภาพกราฟฟิกสามมิติ ฯลฯ

1. "OpenDoc" คําจํากัดความใหมของระบบเปด
สุรพล ศรีบุญทรง
บทความป 1995
"Document-based computing" การประมวลผลรูปใหม
ปรากฏการณสําคัญที่นาสนใจอยางหนึ่งซึ่งปรากฏขึ้นในวงการอุตสาหกรรมคอมพิวเตอรในชวงหลาย
ปที่ผานมานี้ คือ เหลาบริษัทผูผลิตผลิตภัณฑคอมพิวเตอรตางพากันหันเห
ตนเองเขาสูเทคโนโลยีการประมวลผลแบบ Document-based computing
ซึ่งเปนรูปแบบการประมวลผลที่เนนตัวเอกสาร (document) อันเปนผลลัพธ
โดยรวมที่ปรากฏสูสายตาของผูใชคอมพิวเตอรเปนสําคัญ แทนที่จะเนนไปที่
ตัวโปรแกรมประยุกตซึ่งสรางเอกสารดังกลาวขึ้นมา (Application-based
computing) เชนรูปแบบการที่เคยนิยมกันแตไหนแตไรมา
อาจกลาวไดวาการประมวลผลแบบ Document-based
computing นี้เปนรูปแบบการประมวลผลในอนาคตที่เหลาผูใชคอมพิวเตอร
อยางเราๆ ทานๆ คงจะตองสัมผัสใชงานมันอยางแนนอนไมวาจะเปนใน
ขณะนี้ หรืออีกไมกี่ปขางหนา รูปแบบการประมวลผลแบบ Document-
based computing เริ่มเปนที่รูจักกันครั้งแรกก็ในชวงราวๆ คริสตทศวรรษที่ 70 จากผลิตภัณฑของบริษัท Xerox
หลังจากนั้นมันก็ไดรับการพัฒนาใหมีประสิทธิภาพเพิ่มขึ้นอยางตอเนื่องตลอดเวลา
สําหรับรูปแบบของการประมวลผลแบบ Document-based computing ที่เหลาผูใชคอมพิวเตอร
อยางเราๆ ทานๆ รูจักกันเปนอยางดี ก็เห็นจะไดแก ระบบ OLE (Object Linking and Embedding) ของบริษัท
ไมโครซอฟทซึ่งใชวิธีกําหนดองคประกอบภายในเอกสารบนหนาจอคอมพิวเตอรเปนออพเจ็คท (object) หลายๆออพ
เจ็คท (แตละออพเจ็คทอาจจะถูกสรางมาจากโปรแกรมประยุกตเดียวกัน หรือตางโปรแกรมกันก็ได)
ความที่แตละเอกสารซึ่งถูกสรางขึ้นดวยระบบการประมวลผลแบบ Document-based
computing อยาง OLE นี้เปนผลรวมที่เกิดมาจากออพเจ็คทหลายๆ ออพเจ็คท จากโปรแกรมประยุกตหลายๆ
โปรแกรม เราจึงมักจะเรียกเอกสารดังกลาวนี้วาเปน "เอกสารประกอบ หรือ Compound document" และตัว
Compound document นี่เองที่จัดไดวาเปนแกนกลาง หรือหัวใจของระบบการประมวลผลแบบ Document-
based computing

2. 2
ภายใตการทํางานของระบบ OLE นั้น ผูใชคอมพิวเตอรสามารถนําเอาออพเจ็คทรูปตารางหรือ
กราฟแผนผังซึ่งถูกสรางขึ้นจากโปรแกรมประยุกตประเภทสเปรดชีตอยาง โปรแกรม excel, ออพเจ็คทรูปภาพบิท
แม็ทที่ถูกสรางจากโปรแกรมประยุกตประเภท
Art & Letter เขาไปประกอบภายในเอกสาร
ขอความซึ่งสรางขึ้นจากโปรแกรมประเภทเวิรด
ไดอยางสะดวกงายดายและมีประสิทธิภาพ
เวลาจะแกไขดัดแปลงอะไรภายในออพเจ็คทก็
สามารถเรียกโปรแกรมประยุกตซึ่งเปนเจาของ
ออพเจ็คทขึ้นมาทํางานจากตัวเอกสาร
Compound document ไดโดยตรงเลย
ไมวาระบบ OLE จะสามารถ
ประกอบออพเจ็คทตางๆ เขาไวในเอกสาร
Compound document ไดอยางมี
ประสิทธิภาพมากเพียงไรก็ตาม แตมันก็ยังคง
จํากัดการทํางานอยูภายในกลุมของโปรแกรม
ประยุกตที่ถูกออกแบบมาเพื่อการทํางานบน
ระบบปฏิบัติการวินโดวส และทํางานบนเครื่อง
คอมพิวเตอรตระกูลพีซี (PCs) เทานั้น ไม
อนุญาตใหนําเอาออพเจ็คทซึ่งสรางจาก
โปรแกรมประยุกตจากระบบคอมพิวเตอรแมค
อินทอช หรือจากแพล็ตฟอรมอื่นๆ เขามา
ประกอบในตัวเอกสาร Compound document ได (อาจจะนําออพเจ็คทจากตางระบบเขามาประกอบได แตก็ไม
สามารถเรียกโปรแกรมซึ่งเปนเจาของออพเจ็คทกลับขึ้นมาดัดแปลงแกไขออพเจ็คทดังกลาวไดอยูดี)
เพื่อแกปญหาเรื่องขอจํากัดในเรื่องการยายงานไปทําในคอมพิวเตอรแพล็ตฟอรมตางระบบ เหลา
บริษัทผูผลิตซอฟทแวรคอมพิวเตอรรุนหลังๆ จึงพยายามออกแบบผลิตภัณฑของตนใหเปดกวาง และเปนสากล
(open system) มากที่สุดเทาที่จะมากได แนนอน แนวโนมเรื่องความเปนระบบเปดที่วานี้ยอมสงผลกระทบตอ
การประมวลผลแบบ Document-based computing อยางมิอาจหลีกเลี่ยงได ในฐานะที่มันเปนการทํางานบน
เอกสาร Compound document ที่เกี่ยวของกับโปรแกรมประยุกตหลายๆ โปรแกรม
ดังนั้นผลิตภัณฑ Document-based computing รุนลาสุดอยาง "OpenDoc" จึงถูกออกแบบมาให
มีลักษณะเปนกลางสามารถใชไดกับโปรแกรมประยุกตจากเหลาบริษัทผูผลิตไดอยางไมจํากัดยี่หอ (vendor-neutral)
ซึ่งนาจะเปนมาตรฐานระบบเปด (open standard) สําหรับรูปแบบของเอกสาร Compound document ใน

3. 3
อนาคต ที่สามารถประกอบไปดวยขอมูลทุกประเภท ไมวาจะเปน ตาราง, แผนผัง, กราฟ, ตัวอักษร, หรือจนกระทั่ง
สัญญาณวิดีโอ, สัญญาณเสียง, โน็ตการด และภาพกราฟฟกสามมิติ ฯลฯ
เจาะลึกระบบ OpenDoc
ในทางทฤษฎีนั้น OpenDoc จะอนุญาตใหผูใชคอมพิวเตอรดัดแปลงแกไขออพเจ็คททุกออพเจ็คท
ที่ประกอบอยูภายในเอกสาร Compound document ดวยโปรแกรมประยุกตซึ่งเปนเจาของออพเจ็คท (ตอแตนี้ไป
จะเรียกโปรแกรมประยุกตซึ่งเปนเจาของออพเจ็คท และสามารถดัดแปลงแกไขออพเจ็คทไดวา "Editor") ไดอยาง
อิสระไปพรอมๆ กัน (same time editing) มิใชปลอยใหโปรแกรม editor โปรแกรมใดโปรแกรมหนึ่งครอบครอง
เอกสารไปโดยเด็ดขาด เชนรูปแบบการประมวลผลแบบเดิม
การที่ OpenDoc อนุญาตใหโปรแกรม editor หลายๆ โปรแกรมสามารถจัดการกับออพเจ็คท
ภายในเอกสาร Compound document ไปพรอมๆ กันไดนั้น ทําใหจําเปนตองมีการขีดแบงพื้นที่ครอบครองของ
แตละออพเจ็คทแยกจากกันอยางชัดเจนแนนอน (คลายๆ กับการรังวัดที่ดินของกรมที่ดินอยางไรอยางนั้นแหละ) มิ
ฉนั้นอาจจะมีการพิพาท หรือลวงล้ําพื้นที่ใชงานซึ่งกันและกันระหวางโปรแกรม editor และหาขอสรุปไมไดวาใคร
ควรจะเปนผูครอบครองพื้นที่ซึ่งอยูระหวางออพเจ็คท (พื้นที่ใชงานของแตละ editor ของ OpenDoc นั้นมีศัพท
เฉพาะวา "parts")
แตการขีดแบงพื้นที่ครอบครองของแตละออพเจ็คทออกจากกันเปนสวนๆ นั้น ก็อาจจะนําไปสูการ
สูญเสียขีดความสามารถบางอยางของการประมวลผลแบบ Document-based computing เชน ความสามารถใน
การฝงตัวของออพเจ็คท (embedding) เพราะการฝงตัวนั้นหมายถึงวาจะตองมีการลวงล้ําของออพเจ็คทหนึ่งเขาไป
ในสวน part ของอีกออพเจ็คทหนึ่งทั้งตัวเลยเสียดวยซ้ํา และหลังจากการฝงตัวออพเจ็คทหนึ่งเขาไปในอีกออพเจ็คท
หนึ่งแลว แตละออพเจ็คทก็จะตองดํารงสถานภาพเดิมของตนไวอยูตลอดเวลา (คลายกับการฝงลูกเกต หรือหมูหยอง
เขาไวในขนมปงอยางไรอยางนั้น หลังจากฝงตัวแลว ลูกเกตก็ยังเปนลูกเกต, หมูหยองยังเปนหมูหยอง และขนมปงก็
ยังคงเปนขนมปงอยูเชนเดิมไมเปลี่ยนแปลง ไมวาจะเปนเรื่องรูปลักษณที่ปรากฏ หรือรสชาติของมัน)
ดังนั้น คําวา part ของระบบ OpenDoc จึงไมเพียงแตจะหมายถึงพื้นที่ซึ่งแตละออพเจ็คท
ครอบครองอยูเทานั้น แตยังหมายถึงพื้นที่ของออพเจ็คทที่ฝงตัวอยูในอีกออพเจ็คทหนึ่งอีกดวย โดยแตละ part ก็ตาง
มีโปรแกรม editor ของตนเอง ถึงแมวาจะประกอบอยูภายในหนาตางเดียวกันบนหนาจอคอมพิวเตอร (same
window), อยูในไฟลลขอมูลไฟลลเดียวกัน
(same file) และถูกจัดเก็บไวในหนวยความจํา
สํารองเดียวกัน (same disk or same storage
server)
เวลาที่ผูใชคอมพิวเตอรทําการ
ดัดแปลงแกไขขอมูลตางๆ ภายในเอกสาร
Compound document เหลาโปรแกรม

4. 4
editor ซึ่งทําหนาที่รับผิดชอบออพเจ็คทแตละออพเจ็คทอยูก็จะถูกเปดขึ้นมาทํางานรวมกันไป โดยการทํางาน
พื้นฐาน (basic task) ของโปรแกรม editor เหลานี้ ประกอบไปดวย การจัดเก็บขอมูลในออพเจ็คทเขาไวในดิสกใน
กรณีที่จําเปน, จัดสรางภาพรายละเอียดของออพเจ็คทขึ้นบนหนาจอมอนิเตอร หรือสงผานรายละเอียดดังกลาวไปยัง
เครื่องพิมพในกรณีที่มีการสั่งพิมพงาน, และตอบสนองตอการทํางานตางๆ บนออพเจ็คทที่ผูใชคอมพิวเตอรสั่งผานทาง
เมาส หรือคียบอรด
ซี่งในสวนของการตอบสนองของโปรแกรม editor ที่มีตอการคลื้กเมาสหรือกดแปนคียบอรดนั้น
จําเปนอยางมากที่จะตองอาศัยการจัดแบง part ที่ถูกตองชัดเจนบนเอกสาร Compound document ดวยกลุมของ
การทํางานคลังขอมูล libraries ทําใหระบบ OpenDoc มีขอดีเหนือกวาระบบ Object-oriented programing อื่นๆ
เพราะมิไดมีการอางอิงถึงระบบดั้งเดิม (extended through inheritance) ซึ่งจัดสรางแตละออพเจ็คทขึ้นมาเลย
ระบบ OpenDoc เพียงแตนําเอาออพเจ็คทแตละ part เขามาประกอบไวดวยกันภายในเอกสาร
Compound document เทานั้น จึงสามารถประกอบเอาออพเจ็คทจากโปรแกรมประยุกตตางระบบเขามาไว
ภายในเอกสารเดียวกันได โดยไมจํากัดวาออพเจ็คทดังกลาวนั้นจะถูกสรางขึ้นเพื่อระบบปฏิบัติการใด หรือถูกสราง
บนแพล็ตฟอรมคอมพิวเตอรประเภทไหน เวลาที่มีการสรางเอกสาร Compound document สิ่งที่กลุมการทํางาน
libraries ทําก็มีแคเพียงการอางถึงรหัส procedure code ในกรณีที่จําเปน
องคประกอบสําคัญของ OpenDoc
ระบบ OpenDoc ประกอบไปดวยการทํางานสําคัญๆ หลายชนิดที่ถูกใชเพื่อการจัดวางองคประกอบ
ตางๆ ภายในเอกสาร Compound document และการเรียกคนขอมูลองคประกอบเหลานั้น เริ่มดวยการทํางาน
OpenDoc's layout system ซึ่งทําหนาที่ชวยเหลือสนับสนุนหาขอตกลงในการกําหนดตําแหนงเลยเอาท (layout
negotiation help) ของแตละ part บนเอกสาร เพื่อวาจะไดไมมีการวางสวนของ part ซอนกันระหวางออพเจ็คท
การทํางาน OpenDoc's layout system ยังเปนตัวกําหนดวาโปรแกรม editor ใดควรจะถูก
เรียกขึ้นมาทํางาน เมื่อมีการคลื้กเมาสบนหนาจอมอนิเตอรอีกดวย โดยมันไมเพียงแตจะรับรูถึงตําแหนงของออพ
เจ็คท และตัวชี้ของเมาสบนหนาตางที่ปรากฏบนจอมอนิเตอร (on-screen windows) เทานั้น แตยังครอบคลุมไปถึง
ภาพซึ่งไมปรากฏบนหนาจอมอนิเตอร (off-screen bit maps) อีกดวย นอกจากนั้นการทํางาน OpenDoc's
layout system ก็ยังมีสวนรับผิดชอบตอภาพกราฟฟกชนิด 2 มิติ และ 3 มิติ ที่ซอนทับกันอยู และการอัพเดทแตละ
สวนของเอกสารที่กําลังใชงานอยูไปพรอมๆ กันดวย (simutaneous active parts updateing)
การทํางานที่นาสนใจ
ถัดมาของ OpenDoc คือ การทํางาน
"event-dispatching system" ซึ่งทํา
หนาที่กําหนดเสนทาง (routing) ของ
การดําเนินการตางๆ ที่ผูใช
คอมพิวเตอรเรียกใชใหถุกสงตรงไปยัง

5. 5
สวนของ part ที่ผูใชตองการไดอยางถูกตองหมาะสมโดยอาศัยความชวยเหลือจากการทํางาน layout system ทํา
ใหผูใชคอมพิวเตอรสามารถเขาถึงสวน part ของเอกสารที่ตนตองการไดโดยตรง โดยไมจําเปนตองกดคลิ้กเมาสซอน
กันสองครั้ง (double click) หรือเรียกผานเมนูคําสั่งใหยุงยากวุนวาย
ตอจากการทํางาน event-dispatching system ก็คือการทํางาน OpenDoc's storage system
ซึ่งชวยใหสวน part ตางๆ ของเอกสาร Compound document สามารถจัดเก็บบันทึกขอมูลที่สลับซับซอนอยาง
มากนั้นไวภายในไฟลลสวนกลาง (shared file) ไดอยางถูกตอง รวมทั้งยังสามารถจัดเก็บแบบรางเอกสารทีละหลาย
เอกสาร (multiple document drafts storing) และจัดเก็บขอมูลความสัมพันธระหวาง part ที่ถูกฝงตัวไวภายใน
อีก part หนึ่ง (embedding information) ไดดวย
นอกจากนั้น ระบบ OpenDoc ยังประกอบดวยการทํางาน data transfer system ซึ่งชวยจัดสง
ขอมูลจาก part หนึ่งของเอกสาร ไปยังอีก part หนึ่งของเอกสาร (part information shipment) ใหเปนไปอยาง
ถูกตองเหมาะสม ซึ่งขอมูลที่ถุกจัดสงนี้หมายรวมไปถึงขอมูล embeded information ที่ถูกฝงตัวอยูใน part อื่น
ดวย การสงผานขอมูล embeded information นั้น อาจจะโดยผานทางการทํางาน clipboard ของวินโดวส, โดย
วิธีการสรางความเชื่อมโยง (linking) ระหวาง part, หรือโดยการคลิ้กเมาสลากเอาขอมูลที่ตองการเคลื่อนยายไปวางที่
ตําแหนงซึ่งผูใชคอมพิวเตอรตองการ (drag-and drop) ก็ยอมไดทั้งสิ้น
สําหรับองคประกอบการทํางานสุดทายภายในระบบ OpenDoc ก็คือ "scripting system" ซึ่ง
อนุญาตใหผูใชคอมพิวเตอรทําการเชื่อมโยงการทํางานของแตละโปรแกรม editor ซึ่งรับผิดชอบแตละ part ภายใน
เอกสารเขาดวยกันไวไดอยางงายๆ ไมวาความสัมพันธดังกลาวนั้นจะเปนความสัมพัฯธภายในตัวเอกสารเดียวกัน,
ความสัมพันธภายในเครือขายเน็ตเวิรก หรือความสัมพันธระหวางแพล็ตฟอรมที่แตกตางกัน
OpenDoc
ความโดดเดนของระบบ OpenDoc นั้นอยูตรงที่มันเปนโครงสรางทางสถาปตยที่คาบเกี่ยวระหวาง
คอมพิวเตอรตางระบบ (cross-platform architecture) สามารถรองรับการทํางานของโปรแกรมประยุกตที่ถุกออก
แบบมาใหทํางานตางระบบกันได และรวมทั้งยังมีความสามารถในการจัดการกับกระบวนการการทํางานภายใตเอนวิ
รอนเมนท GUI environments ที่แตกตางกันไปไดอยางไมจํากัดอีกดวย
ที่วามันสามารถตอบสนองตอการทํางานภายใต GUI envirinemnt ที่ตางๆ กันไปนั้น ก็เชนถาเปน
เอนไวรอนเมนท X Window System มันก็จะตอบสนองตอการกดคียบอรดดวยการเรียกไปที่ตําแหนงการทํางานบน
หนาตางที่เคอรเซอรกําลังวางอยู, แตถาเปนเอนไวรอนเมนทของ Macintosh มันก็จะตอบสนองตอการกดคียบอรืด
ดวยการเรียกไปที่หนาตางที่อยูบนสุด (frontmost window) พรอมกับเรียกไปที่บริเวณซึ่ง insertion point วาง
แทรกอยู
สําหรับในเอนไวรอนเมนทอื่นๆ ระบบ OpenDoc ก็จะมีรูปแบบการตอบสนองตอการคลิ้กเมาส
หรือกดคียบอรดแตกตางกันไปตามความเหมาะสม เรียกไดวาระบบ OpenDoc นั้นมีความยืดหยุนอยางมากตอการ
ตอบสนองผูใชในแตละสวน part ของเอกสาร ขึ้นอยูกับวาผูใชกําลังติดตอกับรูปแบบเอนไวรอนเมนทอะไรอยู และ

6. 6
ความยืดหยุนดังกลาวนี้ยังครอบคลุมลงมาถึงการทํางานตางๆ ภายในเอกสารอีกดวย โดย OpenDoc จะติดตอกับ
ผูใชคอมพิวเตอรดวยรูปแบบที่ตางๆ กันออกไปขึ้นอยูกับวาการติดตอนั้นๆ เปนการเรียกใชเมนูคําสั่ง, หนาตาง, คลิป
บอรด, หรือชองไดอะล็อกซ บ็อกซ ฯลฯ
อยางไรก็ตาม ความพยายามในการคงรูปแบบการติดตอกับผูใช (human interface
environment)ไวในรูปแบบใดรูปแบบหนึ่งซึ่งผูใชคอมพิวเตอรสามารถทําความเขาใจ และคุนเคยไดโดยงาย แมวาจะ
มีการติดตอกับแพล็ตฟอรมตางระบบกันนั้น ไดนํามาซึ่งความยากลําบากเปนอยางมากในการออกแบบใหกับทีมงาน
ผูผลิตระบบ OpenDoc ทางออกของปญหาดังกลาวมีอยูสองทาง ทางแรก คือ ใชวิธีการติดตอกับผูใชแบบ
ผสมผสานระหวางรูปแบบที่ใชบนหลายๆ แพล็ตฟอรมรวมกันไปเลย (collection of each platform) สวนทางออก
ที่สอง ก็โดยการหาขอสรุปจากปญหาตางๆ ที่ผูใชอาจจะตองประสบแลวสรางเปนรูปแบบการติดตอใหมที่สามารถเขา
ไดกับแพล็ตฟอรมแตละแพล็ตฟอรม
และทางออกที่สองนี่เองที่ถูกทีมงานผูออกแบบระบบ OpenDoc เลือกนํามาใชกับระบบของตน
ดวยการจัดสรางการทํางานหลักขึ้นมาสองอยาง คือ Dispatcher และ Arbritator โดย Dispatcher นั้นเปนออพ
เจ็คทซึ่งทําหนาที่ชวยเหลือสวนการทํางาน Dispatcher* ของระบบปฏิบัติการที่กําลังทํางานอยูในขณะนั้น
(underlying platform) ในการคนหาโปรแกรม editor ที่เหมาะสมใหกับสวนของเอกสารที่ถูกเรียกใช
ในขณะที่สวน Arbitrator จะเปนวิถีทางสําหรับสวน part ตางๆ ของเอกสารใชในการระบุให
โปรแกรม Dispatcher ทราบวาโปรแกรม editor ใดเปนผูรับผิดชอบตอสัญญาณคียขอมูลที่ถูกปอนผานเขามาทาง
คียบอรด หรือแถบเมนูคําสั่งโดยผูใชคอมพิวเตอร และดวยการทํางานที่ผสมผสานกันระหวาง Dispatcher และ
Arbitrator นี่เองที่เปนหลักสําคัญอันทําใหระบบ OpenDoc สามารถทํางานรวมกับรูปแบบการติดตอกับผูใชซึ่ง
แตกตางกันอยางมากระหวางแพล็ตฟอรมคอมพิวเตอรตางระบบได
การที่บอกวา Arbitrator เปนวิถีทาง (way) สําหรับ part ในการติดตอกับสวน Dispatcher อาจจะ
ไมถูกตองเสียทีเดียวนัก อันที่จริงแลว สวน Arbitrator เปนเพียงตาราง (table) ที่แสดงใหระบบ OpenDoc
ทราบวามีทรัพยากรใดถูกครอบครองอยูโดย part ใดบางในชั่วขณะหนึ่ง โดย Arbitrator จะรับรูถึงทรัพยากรตางๆ
ภายในระบบคอมพิวเตอรในสถานะที่เปน focus หนึ่งๆ เวลาที่มีการเรียกใชงาน part ของเอกสารแตละครั้ง สวน
Arbitrator ก็จะตอบสนองดวยการเปดเอากลุมของ focus ตางๆ ที่สัมพันธกันขึ้นมา
ซึ่งขั้นตอนการเปดเอาทรัพยากรตางๆ ในรูปของ focus ออกมาโดย Arbitrator นั้นจะประกอบไป
ดวยการทํางานสองชวงดวยกัน (two-phase commit mechanism) ชวงแรกเริ่มดวยการที่ Arbitrator รองขอตอ
part ตางๆ ที่กําลังครอบครองทรัพยากรอยูสละสิทธิในการครอบครองเสียกอน(ownership giveup) แลวจึงคอย
กําหนดสิทธิในการครอบครองทรัพยากรใหกับผูครอบครองใหมในชวงถัดมา (ownership reassign)
ประโยชนที่เห็นไดชัดเจนของการจัดแบงสิทธิในการครอบครองทรัพยากรสวนกลางในระบบของ
Arbitrator ก็ไดแก การที่โปรแกรม editor ของ part หนึ่งกําลังครอบครองสิทธิในสวนของเมนูบารอยู พรอมๆ กับ
ที่โปรแกรม editor ของอีก part หนึ่งก็กําลังครอบครองสิทธิในสวนของการกดแปนคียบอรดอยู หากแตละ
โปรแกรม editor ตางก็ตองการจะใชสิทธิในสวนของทรัพยากรที่อีกโปรแกรม editor กําลังครอบครองอยู โดยไม

7. 7
ยอมยกเลิกสิทธิครอบครองของอีกฝายหนึ่งเสียกอนแลวละก็ ระบบคอมพิวเตอรคงตองเกิดสภาวะการแฮงค
(deadlock) ไมสามารถทํางานตอไปไดอยางแนนอน
รูปแบบการทํางานผสมผสานกันระหวาง Dispatcher และ Arbitrator ของระบบ OpenDoc ที่
กลาวผานมานี้ สําหรับผูอานที่คุนเคยอยูกับการประมวลผลในระบบเครือขายเน็ตเวิรก (network) หรือการ
ประมวลผลหลายหนวยประมวลผล (multiprocessing) คงจะไมรูสึกวามันแปลกใหมนาสนใจสักเทาใดนัก เพราะ
มันก็คลายๆ กับเทคนิคที่ใชปองกันการแฮงคของระบบอันเนื่องจากการแยงใชทรัพยากร (deadlock involving
resource) ซึ่งเปนที่รูจักกันทั่วไปอยูแลวนั่นเอง
แตที่สวน Arbitrator ของระบบ OpenDoc มีเหนือกวาการจัดแบงทรัพยากรอื่นๆ เห็นจะอยูตรงที่
มันถูกออกแบบใหสามารถขยายขอบขีดความสามารถขึ้นไปได (extensibility) ทําใหสามารถรองรับการทํางานของ
อุปกรณฮารดแวร หรือโปรแกรมประยุกตรูปแบบใหมที่จะถูกเสริมเขามาไดอยางไมจํากัด เวลาที่จะมีการเสริม
Arbitrator focus ใหมๆ เขามาภายในระบบ OpenDoc ก็เพียงแตจัดสรางอ็อพเจ็คทใหมขึ้นมาในชื่อ focus
module เพื่อเสริมเพิ่มเขาไปในสวน Arbitratorที่มีอยูเดิมในระบบ OpenDoc ไดเลย
ยอนกลับมาพูดเรื่องการตอบสนองตอสัญญาณอินพุทที่ผูใชคอมพิวเตอรปอนเขามาอีกทีหนึ่ง ปรกติ
ในระบบปฏิบัติการสมัยใหมทั่วไปที่ติดตอกับผูใชผานหนาตาง (windows) จะสงสัญญาณที่อินพุทที่ผูใชปอนเขามาไป
ยังหนาตางที่เปดอยูโดยตรงเลย แตสําหรับระบบ OpenDoc ที่แตละหนาตางประกอบไปดวยหลายๆ part แลว
จําเปนตองมีการจัดสงสัญญาณอินพุทไปยัง part ที่เหมาะสมเพิ่มขึ้นมาอีกขั้นตอนหนึ่งหลังจากที่ระบบจัดสงสัญญาณ
อินพุทไปยังหนาตางแลว ซึ่งหนาที่ในการจัดสงสัญญาณอินพุทไปยังสวน part ที่เหมาะสมภายในระบบ OpenDoc
นั้น ก็คือหนาที่โดยตรงของการทํางาน Dispatcher นั่นเอง
และสําหรับที่บางระบบปฏิบัติการที่จําเปนตองมีการเชื่อมโยงระหวางหนาตางๆ หลายหนาตางเขา
ดวยกันเปน nested windows เพื่อใชกับงานประมวลผลที่มีการฝงตัวของออพเจ็คทภายในเอกสาร ระบบ
OpenDoc ก็จําเปนตองใชระบบเลยเอาทแบบ frame ที่มีความสลับซับซอนขึ้นเพื่อรองรับการทํางานดังกลาว โดย
การทํางาน frame นั้นจะจัดแบงสวนตางๆ ภายในหนาตางออกเปนพื้นที่ยอยๆ แยกจากกัน ทําใหระบบ OpenDoc
สามารถรองรับการประมวลผลประเภทที่มีการใชพื้นที่บางสวนของหนาตางซอนทับกัน (เชน การทํางานในระบบ
มัลติมีเดีย) ไดอยางไมมีปญหา
สวนของระบบ OpenDoc ที่ดูเหมือนจะไดรับความสนใจเปนพิเศษสําหรับผูคนในวงการ
คอมพิวเตอรนั้นเห็นจะไดแกวิธีการที่ OpenDoc ใชในการติดตอกับหนวยความจํา เพราะปจจุบันนี้เรามีรูปแบบ
ฟอรแมทไฟลลที่ใชในการจัดเก็บขอมูลที่หลากหลายมากมายเสียเหลือเกิน แตละแพล็ตฟอรมคอมพิวเตอร และแต
ละประยุกตก็ตางลวนมีรูปแบบฟอรแมทที่จําเพาะตัวของตนเองดวยกันทั้งสิ้น จนแมกระทั่งในโปรแกรมประยุกต
ชนิดเดียวกัน หากถูกนําไปใชกับเครื่องคอมพิวเตอรตางระบบกันก็ยังมีการใชฟอรแมทของไฟลลแตกตางกันไปเลย
แนนอน การเลือกใชฟอรแมทของการจัดการกับหนวยความจําใหอยูในรูปแบบเดียวกันเสียหมดทุก
ระบบ ยอมจะนํามาซึ่งความสะดวกสบายสําหรับเหลาผูพัฒนาโปรแกรมประยุกตในการที่จะอัพเกรดเสริมรูปแบบ
การทํางานใหมๆ ใหกับการประมวลที่มีอยูเดิม แตในความเปนจริงแลว การเลือกใชรูปแบบฟอรแมทของไฟลลที่ใช

8. 8
จัดเก็บขอมูลก็เปนเรื่องที่ไมสามารถกระทําไดอยางงายดายนัก จําเปนตองมีการชั่งน้ําหนักระหวางผลดีผลเสียหลายๆ
อยางเขาดวยกัน
ผูพัฒนาโปรแกรมประยุกตจําตองตัดสินใจเลือกระหวางความเปนมาตรฐาน(standard) กับความ
เปนนวัตกรรม (innovation) ปญหานี้จะเกิดขึ้นเมื่อผูพัฒนาโปรแกรมตองการเสริมรูปแบบการทํางานชนิดใหมๆ
(new features) เพิ่มเขาไปในผลิตภัณฑโปรแกรมซอฟทแวรของตน แตในโปรแกรมเดิมก็มีรูปแบบฟอรแมทของ
ไฟลลที่แนนอนอยูแลว (หรือวาโปรแกรมประเภทเดียวกันนี้ที่มีจําหนายอยูในทองตลาดมีการใชรูปแบบฟอรแมทซึ่งมี
ลักษณะแนนอนอยูแลว)
ซึ่งถาผูพัฒนาโปรแกรมประยุกตทานนี้มุงไปที่เนนเรื่องนวัตกรรมใหมเพียงอยางเดียว ก็คงนําเสนอ
การทํางานที่พัฒนาขึ้นมาใหมนั้นเขาสูตลาดไปเลย แตถาสนใจเรื่องาตรฐานก็คงตองใชเวลาดัดแปลงการทํางาน
ดังกลาวใหเขากันไดกับมาตรฐานที่มีอยูเดิมในทองตลาดเสียกอน และก็คงตองกินเวลานานพอสมควรเพราะรูปแบบ
ฟอรแมทไฟลลปรกติทั่วๆ ไปมักจะไมอนุญาตใหดัดแปลงเสริมแตงอะไรไดงายๆ
นอกจากนั้น ผูพัฒนาโปรแกรมประยุกตยังตองตองตัดสินใจเลือกระหวางความสะดวกในการ
เผยแพร (publication) กับความ
มีประสิทธิภาพในการปรับปรุง
(efficiency editting) อีกดวย
ซึ่งเปนปญหาที่เกิดขึ้นเมื่อ
จําเปนตองนําเสนอไฟลลฟอรแมท
ในมาตรฐาน standard
interchange format ที่สามารถ
แลกเปลี่ยนระหวางระบบได
โดยปรกติรูปแบบฟอรแมทแบบ
interchange format นี้มักจะถูกออกแบบใหมีลักษณะเปนกลางๆ ไมเขากับรูปแบบฟอรแมทใดฟอรแมทหนึ่งอยาง
แนนอนลงไป เพื่อใหงายสําหรับการอาน และการขยับขยายไปใชกับระบบฟอรแมทอื่นๆ
แตก็อีกนั่นแหละ ความสะดวกในการเผยแพรของรูปแบบฟอรแมทแบบ interchange format นั้น
ตองแลกมาดวยการที่มันถูกออกแบบมาอยางครึ่งๆ กลางๆ ไมสามารถทําการดัดแปลงแกไขไดอยางมีประสิทธิภาพ
(unefficiency editting) หรือไมสามารถทํางานใหสมรรถนะประสิทธิภาพของมันบนคอมพิวเตอรบางระบบได (lack
of performance) ซึ่งทางออกสําหรับกรณีนี้ที่นิยมใชกันก็เห็นจะไดแกการที่ผูผลิตโปรแกรมประยุกตออกแบบ
ผลิตภัณฑของตนใหสามารถรองรับฟอรแมทของไฟลลไดหลายรูปแบบ แตเวลาจะทํางานตองมีการแปลงรูปแบบ
ฟอรแมทใหอยูในรูปแบบของตนเองเสียกอน (rewritten)
อยางไรก็ตาม การที่เอกสาร Compound document ประกอบไปดวยองคประกอบหลายๆ part
และแตละ part ก็ตางมีรูปแบบฟอรแมทของตนเอง ทําใหมันเปนเรื่องหลีกเลี่ยงไมไดเลยที่จะตองมีการใชรูปแบบ
ฟอรแมทของไฟลลมากกวาหนึ่งชนิดภายในเอกสาร และปญหาที่ตามมาก็คือ ฟอรแมทไฟลลเหลานี้มักจะผสมผสาน

9. 9
กันไดไมคอยจะกลมกลืนนัก ระหวางไฟลลฟอรแมทประเภทที่งายตอการดัดแปลงแกไข (efficient editing) กับไฟลล
ฟอรแมทประเภทสะดวกตอการเผยแพร (efficient publication)
โดยไฟลลฟอรแมทที่งายตอการดัดแปลงแกไขนั้น มักจะจะใชวิธีจัดการกับขอมูลทีละเปนกลุมๆ
(based on string of bytes) และสามารถเขาถึงกลุมขอมูลเหลานี้ไดโดยวิธีสุม (Random access) ผานทางตาราง
ระบุตําแหนงขอมูล เพื่อวาจะสามารถดัดแปลงแกไขขอมูลภายในไฟลลไดอยางรวดเร็ว และมีประสิทธิภาพ แตก็
สงผลใหตองพึ่งพิงโปรแกรม editor เพื่อดัดแปลงแกไขขอมูลเหลานี้เปนการเฉพาะ
ในขณะที่ไฟลลฟอรแมทประเภทที่ออกแบบมาใหงายสําหรับการเผยแพร (efficient publication)
นั้น มักจะใชวิธีติดตอกับขอมูลทีละไบททีละไบทเรียงกันไปตามลําดับเหมือนสายพานลําเลียง (stream oriented)
จึงงายสําหรับการรับรูโดยโปรแกรมประยุกตทั่วๆ ไป ดังนั้น เมื่อจําเปนตองนําเอาไฟลลฟอรแมทแบบ efficient
publication ที่เขาถึงขอมูลตามลําดับ มาผสมผสานเขากับไฟลลฟอรแมท efficient editing ที่เขาถึงขอมูลอยางสุม
ทีละกลุมคํา จึงยอมนํามาซึ่งความสับสนของลําดับขอมูลอันมิอาจหลีกเลี่ยงได
เชน ถาเราพยายามสอดกลุมขอมูลของ efficient publication เขาไปในลําดับขอมูลของ efficient
editing จะเกิดขอขัดแยงอันไมสามารถยอมรับได (unacceptable constraint) วาจะเติมกลุมคําใหมเขามาเมื่อไหร
และอยางไร ในทางกลับกันการสอดขอมูลแบบเรียงตามลําดับของ efficient publication เขาไปในกลุมคําของ
efficient editing ปญหาก็จะอยูตรงที่วาควรจะสอดกลุมคําขนาดความยาวเทาไรดี และมันไมมีทางสอดเขาหรือดึง
กลับขอมูลเหลานั้นไดอยางถูกตองเลยหากไมทราบถึงตารางกลุมขอมูล piece-table structure ของฟอรแมท
efficient editing ดังนั้น เพื่อแกปญหาเรื่องความไมผสมผสานกลมกลืนระหวางไฟลลฟอรแมทดังกลาว ระบบ
OpenDoc จึงใชวิธีการเปดไฟลลชั่วคราวในรูปฟอรแมท metafile ขึ้นมาเพื่อจัดเก็บไฟลลฟอรแมท efficient
publication และ efficient editing ไวดวยกัน
ถึงแมวาระบบ OpenDoc จะสามารถรองรับรูปแบบฟอแมทการจัดเก็บขอมูลที่แตกตางกันออกไป
ไดอยางหลากหลาย แตมันก็จําเปนตอง กําหนดคากําหนดระบุแพล็ตฟอรม
(platform implementation) สําหรับแตละ ฟอรแมทดวยการอางอิงถึงรูปแบบ
ฟอรแมท Bento อันเปนรูปแบบฟอรแมท สําหรับจัดเก็บขอมูลเอกสาร
Compound document ซึ่งไดรับการ พัฒนาขึ้นโดยบริษัท Appleโดยแบบ
ฟอรแมท Bento นี้จะถุกออกแบบใหสามารถ จัดเก็บขอมูลตางฟอรแมทไดอยาง
หลากหลาย สามารถรองรับการทํางานแบบ มัลติมีเดียไดอยางมีประสิทธิภาพ อีก
ทั้งสามารถนําไปใชบนเครื่องคอมพิวเตอรตาง แพล็ตฟอรมไดอยางไมจํากัด
ผลจากการอางอิงถึงรูปแบบฟอรแมท Bento นั้น ทําใหระบบ OpenDoc สามารถจัดการขอมูล
ภายในหนวยความจําไดโดยไมจําเปนตองคํานึ่งถึงวาขอมูลดังกลาวจะถูกจัดเก็บแบบเรียงลําดับ (sequential) หรือถูก
จัดไวเปนกลุมๆ (piece-based) รวมทั้งยังไมตองใสใจวาการเขาถึงขอมูลดังกลาวนั้นจะเปนไปในแบบสุม (random
access) หรือเปนไปแบบตามลําดับ (sequential access)

10. 10
ในการอธิบายถึงรูปแบบการจัดการกับหนวยความจําของระบบ OpenDoc นั้น จําเปนตอง
เปรียบเทียบกับแบบจําลองหนวยความจํา (OpenDoc's storage model) อันประกอบไปดวยพื้นที่ขอบเขตการ
จัดเก็บขอมูลพื้นฐานที่มีชื่อเรียกวา "value" ซึ่งถูกรับรูโดยโปรแกรม editor คลายกับวาเปนไฟลล ไฟลลหนึ่ง
สามารถอาน, บันทึก, หรือเรียกคนโปรแกรมภายในขึ้นมาทํางานได ไมตางไปจากไฟลลปรกติทั่วๆ ไป
นอกจากสวนของ Value ขึ้นมา แบบจําลองระบบ OpenDoc ก็ยังมีการรองรับสองคําสั่ง
ดําเนินการสําคัญซึ่งกระทําตอขอมูลภายในหนวยความจําอีกดวย สองคําสั่งที่วานั้นคือ "คําสั่งลบขอมูล (delete)"
และ "คําสั่งสอดแทรกขอมูล (insert)" โดยการทํางานทั้งสองอยางนี้เมื่อเกิดขึ้นบนแบบจําลองระบบ OpenDoc จะ
มิไดมีการลบ หรือสอดแทรกขอมูลเขาไปภายในลําดับขอมูลซึ่งอยูในสวน value จริงๆ ไมมีการก็อปปขอมูลจํานวน
มากมายภายใน value ไปมาใหสับสน
คําสั่ง delete และ insert ในระบบ OpenDoc เพียงแตใชวิธีการจัดการกับตาราง table of
content ซึ่งระบุตําแหนงของขอมูลที่ถูกสับเปลี่ยนไปเทานั้น สวนของขอมูลที่ถุกบันทึกอยูในหนวยความจํายังคงอยู
ในตําแหนงเดิมที่มันอยู เหมือนเดิมทุกประการ ดังนั้น ไมวาจะเปนการสอดแทรกขอมูลฟอรแมท sequential
format หรือ piece-based format เขามาภายในกลลุมขอมูลเดิม ก็ตางลวนไมทําใหเกิดปญหากับหนวยความจํา
เดิมแตอยางไร เพราะการสอดแทรกนั้นเกิดขึ้นในระดับตารางระบุตําแหนงเทานั้น มิไดเกิดขึ้นบนลําดับจริงของ
ขอมูล
ในหนวยความจําของระบบ OpenDoc นั้น จะประกอบไปดวย value หลายๆ value และมีการ
จัดเก็บ value เหลานี้ไวเปนกลุมๆ ในอ็อพเจ็คทที่เรียกวา "storage unit" ซึ่งแตละ part บนเอกสารของ OpenDoc
ก็จะมีหนวย stroge unit จําเพาะตัวของตนเอง อันประกอบไปดวยลิสตรายการระบุชนิด และรายละเอียดของ Valu
(list of named properties) ที่จัดเก็บอยูภายใน storage unit นั้นๆ วามีอะไรบาง จะวาไปแลว storage unit ก็
คลายๆ กับไดเร็กตอรี่ในระบบ DOS และ Windows นั่นเอง
แตที่ตางไปจากไดเรกตอรี่ทั่วๆ ไปนั้น อยูที่ Storage unit ของระบบ OpenDoc สามารถจัดเก็บ
ขอมูลหลายๆ ฟอรแมทไวภายใน value เดียวกันได ในขณะที่ในระบบไฟลลของ DOS หรือ Windows นั้นจะ
สามารถจัดเก็บไวดวยขอมูลฟอรเดียวเทานั้น ทําใหการจัดการขอมูลในหนวยความจําแบบ storage unit ของระบบ
OpenDoc มีความเหมาะสมอยางมากสําหรับรองรับการทํางานแบบเอกสาร Compound document ที่มีหลายๆ
part ประกอบเขาดวยกัน และทําใหโปรแกรม editor ที่รับผิดชอบแตละ part บนเอกสารจัดการแกไขดัดแปลง
หรือจัดเก็บขอมูลบน part
ไวภายใตชื่อเดียวกันได
โครงสราง
การจัดเก็บขอมูลใน
หนวยความจําของระบบ
OpenDoc ที่ถัดจากสวน
storage unit ขึ้นมาก็คือ

11. 11
สวนที่มีชื่อเรียกวา "draft" ซึ่งเปนลิสตรายการของ storage unit หลายๆ หนวยประกอบเขาดวยกัน โดยขอมูลใน
draft นี้จะมิใชคาตายตัวของขอมูลในเอกสาร Compound document แตจะเปนคาในชั่วขณะ (snapshot state)
หรือพูดงายๆ ก็คือเปนแบบรางซึ่งสามารถเรียกกลับมาดูไดในภายหลัง ถึงแมวาตัวเอกสารจริงๆ จะมีการ
เปลี่ยนแปลงแกไขใหตางไปจากเดิมแลว ทําใหการทํางานของ OpenDoc เปนไปไดอยางมีประสิทธิภาพ เพราะไมวา
จะมีคําสั่งดําเนินการอะไรติดตามมา (คําสั่งที่วาอาจจะเปน insert, delete, read, write etc.) การดําเนินการที่
เกิดขึ้นจริงก็เพียงแตเปลี่ยนแปลงจากคา draft สุดทายเทานั้น
ความโดดเดนเปนพิเศษของการจัดเก็บขอมูลเอกสารไวในรูป draft นั้น อยูตรงที่มันอนุญาตให
values ที่จัดเก็บอยูภายในสามารถอางอิงถึง storge units ตางๆ ในหนวยความจําไดโดยมิไดจํากัดวาโครงสรางการ
จัดเก็บหนวยความจํานั้นจะมีความสลับซับซอนใหญโตเพียงไรและ value ในหนวย storage หนึ่งสามารถอางอิงถึง
storage unit อื่นๆ ใน draft เดียวกันไดอยางอิสระ
และดวยการอางถึงกันไดอยางอิสระระหวาง value และ storage unit นี้เอง ก็ทําใหโครงสราง
แบบ Draft ของระบบ OpenDoc สามารถรองรับการจัดโครงสรางภายในหนวยความจําไดสารพัด ไมวาจะเปน
โครงสรางงายๆ ที่มีการแตกสาขาไมมาก ไปจนกระทั่งโครงสรางแบบ hypertext ที่มีการอางถึงขอมูลใน
หนวยความจําอื่นๆ อยางสลับซับซอน (ไมเหมือนการจัดการหนวยความจําแบบ DOS หรือ Windows ที่ถามีการอาง
ถึงไฟลลในไดเรกตอรี่ที่ไมมีการใส path หรือกําหนด registration ไวแลว อาจจะทําใหเครื่องแฮ็งคเอาไดงาย)
ทุกๆ โครงราง draft ของเอกสารจะมีสวนของ part ทําหนาที่เปนตัวชี้ตําแหนง (pointer) อยู
ตําแหนงบนสุดของเอกสารเรียกวา "root part" ซึ่งถูกใชเพื่อการเปดโครงราง draft ขึ้นปรากฏเปนหหนาตางบน
จอมอนิเตอร หรือเพื่อสั่งพิมพเอกสารออกทางเครื่องพิมพที่ตอพวงอยู ในขณะที่สวนของ part อื่นๆ ที่ถูกฝงตัวอยู
ในเอกสารจะถูกดําเนินการลักษณะดังกลาวผานทางกลไกการอางอิง (reference mechanism) ของระบบ
OpenDoc ทําใหเอกสารของ OpenDoc สามารถจัดโครงสรางตางๆ กันไปไดอยางมากมาย ขึ้นอยูกับสวน root
part ซึ่งเปน part หลักของเอกสารถุกกําหนดไวอยางไร
เชน ถาตัว root part ถูกกําหนดให
เปนโครงสรางแบบตารางสเปรดชีต สวนของ part
อื่นๆ ที่จะนํามาฝงตัวก็จะตองอยูบนตารางหลัก (main
sheet) เทานั้น แตถาตัว root part ถูกกําหนดดวย
Rolodex editor สวนของ part ที่จะนํามาฝงตัวก็
สามารถที่จะนําไปใสไวใน card ใดๆ กไดใน Rolodex
ฯลฯ (ขอมูลจาก part เดียวกันสามารถถูกนําไปฝง
ตัวไวในตําแหนงตางๆ กันไดโดยไมมีปญหา)
แบบจําลองระบบ OpenDoc ยังมีการจัดเอกสารที่ประกอบไปดวยลิสตรายการของ draft ลวนๆ
อีก ภายในเอกสาร darft ที่มีชื่อเรียกวา "current draft" ใชนําเสนอถึงสถานะลาสุดของเอกสาร (latetest state
document) อันเปนสิ่งที่ปรากฏสูสายตาผูใช OpenDoc เวลาที่มีการเปดเอกสารขึ้นมาดู และนับเปนรูปแบบการ

12. 12
ทํางานซึ่งทําใหระบบ OpenDoc มีความโดดเดนเหนือกวาการประมวลผล Compound document อื่นๆ ที่เคยมีมา
ทั้งหมด ที่สําคัญ มันยังทําใหโปรแกรม editor ซึ่งรับผิดชอบ part บนเอกสาร สามารถใหความสําคัญกับการ
ดําเนินการสวน I/O operation ไดอยางเต็มที่โดยไมตองไมเสียเวลากับการดําเนินการอื่นๆ
ชุดคําสั่ง Scripting ของ OpenDoc
การออกแบบชุดคําสั่ง Scripting ของ OpenDoc นั้นเขาใจวามีจุดมุงหมายหลักอยูสองประการ
ดวยกัน อยางแรกคือมันจะตองเปนชุดคําสั่งที่มนุษยสามารถเขาใจไดโดยงาย (human interface) โดยเฉพาะผูใช
โปรแกรมทั่วๆ ไป ไมใชผูเชี่ยวชาญ หรือโปรแกรมเมอรที่ตองรูจักภาษา C เปนอยางดีจึงจะสามารถใชได อยางที่
สอง ชุดคําสั่ง Scripting นั้นจะตองมุงเนนไปเพื่อการปฏิบัติงานใหบรรลุลวงถึงเปาหมายเปนสําคัญ โดยไมติดขัดวา
จะตองนําเอาการทํางานรูปแบบใดเขามาประกอบกับการดําเนินการบาง
อยางไรก็ตาม จุดมุงหมายทั้งสองประการนี้มิใชสิ่งที่สามารถบรรลุไดอยางงายๆ เลย ลําพังแคที่วา
จะทําใหเปนชุดคําสั่งที่มนุษยสามารถเขาใจไดโดยงายก็เปนเรื่องมหาหินหนักหนาสาหัสอยูแลว เพราะปรกติแลว
ชุดคําสั่ง Scripting ของโปรแกรมประยุกตตางประเภทกันก็มักจะมีรูปแบบการทํางานพื้นฐานที่แตกตางกันไป มาก
บางนอยบาง
เชน ถาเปนชุดคําสั่ง Scripting สําหรับโปรแกรมประเภท Word processor วิธีการจัดเก็บขอมูล
ที่ดีที่สุดก็เห็นจะเปนการใสรหัสแบบ internally, run-length encoding นั่นเอง แตสําหรับการเขียนโปรแกรมดวย
ชุดคําสั่ง Scripting แลว ผูใชโปรแกรม Word processor คงจะไมคาดหวังวาตนเองจะตองติดตอเกี่ยวของกับการใส
รหัสแบบ run-length encoding ซึ่งคอนขางจะตองอาศัยความรูในเรื่องฮารดแวรอยางมากมาประกอบการทํางาน
ดวยเปนแน สิ่งที่ผูใช Word processor ตองการจากชุดคําสั่ง Scripting นาจะเปนเพียงคําสั่งงายๆ ที่เขาสามารถ
จะใชกําหนดรูปแบบเอกสาร, แบบตัวอักษร, ยอหนา ฯลฯ เทานั้น
สวนจุดมุงหมายประการสองของชุดคําสั่ง Scripting ที่เกี่ยวของกับการดําเนินการซึ่งมุงเนนที่
ผลสําเร็จเปนสําคัญนั้น ก็เปนอีกเรื่อง
ที่ทีมผูออกแบบ OpenDoc ให
ความสําคัญไมดอยกวาเรื่องการติดตอ
ที่งายตอการเขาใจสําหรับผูใช
โปรแกรม เพราะตามปรกติแลวการ
ทํางานบนเอกสารของ OpenDoc
มักจะตองประกอบไปดวยกระบวนการ
ทํางานหลายๆ อยางบนรูปแบบ
ฟอรแมทขอมูลหลายๆ แบบ
ดังนั้น หากตองการ
ใหชุดคําสั่ง Scripting สามารถทํางานไดบรรลุผลสําเร็จก็หมายความวาชุดคําสั่ง Scripting ของ OpenDoc จะตอง

13. 13
สามารถติดตอกับกระบวนการทํางานที่แตกตางกันเหลานั้นไดอยางถูกตองเหมาะสม และมีประสิทธิภาพ ซึ่งบางครั้ง
มิไดจํากัดอยูเฉพาะการติดตอกับ part หลายๆ part บนเอกสาร Compound document เดียวกันเทานั้น แตยัง
หมายรวมถึงการติดตอกับเอกสาร Compound document หลายๆ เอกสาร, การติดตอระหวางเครื่องคอมพิวเตอร
ตางระบบ, หรือจนกระทั่งการติดตอระหวางเครือขายเน็ตเวิรกที่ตางกันออกไปอีกดวย
การออกแบบชุดคําสั่ง Scripting ของ OpenDoc ใหบรรลุจุดมุงหมายหลักทั้งสองจึงนับไดวาเปน
เรื่องโหดมหาหินมิใชนอย และสําหรับทางออกของปญหาดังกลาวนี้ ทางทีมงานผูออกแบบ OpenDoc ตกลงใจที่ใช
โครงสรางทางสถาปตยแบบ OSA (Open Scripting Architecture) อันเปนโครง
สรางการจัดการกับชุดคําสั่ง Scripting บนเครื่องคอมพิวเตอร Macintosh ของบริษัท Apple เปนจุดตั้งตนสําหรับ
ชุดคําสั่ง Scripting ที่ตนจะพัฒนาตอไป
โครงสรางทางสถาปตยแบบ OSA นี้ ประกอบดวยโปรแกรม library ที่นาสนใจหลายๆ โปรแกรม
อยางเชนโปรแกรม Apple Events ที่อนุญาตใหโปรแกรมประยุกตตางๆ สามารถเรียก (call) เอาโปรแกรมประยุกต
อื่นๆขึ้นมาทํางานได โดยมิไดจํากัดวาอีกโปรแกรมประยุกตหนึ่งนั้นอยูบนเครื่องคอมพิวเตอรเครื่องเดียวกัน หรืออยู
บนเครื่องคอมพิวเตอรอื่นในเครือขายเน็ตเวิรกเดียวกัน ทําใหชุดคําสั่ง Scripting ของระบบ OSA สามารถเชื่อมโยง
การทํางานระหวางโปรแกรมประยุกตหลายๆ โปรแกรม และระหวางเครื่องคอมพิวเตอรหลายๆ ระบบ ใหทํางาน
ตอเนื่องกันไปไดดวยการใชคําสั่ง scriopt เพียงคําสั่งเดียวเทานั้น
โปรแกรม library ที่นาสนใจอีกโปรแกรมของระบบ OSA ก็คือ โปรแกรม Apple Events Manager ซึ่งทํางาน
สนับสนุนโปรแกรม Apple Events และทําใหการเรียก (call making) หรือการตอบรับ (call recieving) ของ
โปรแกรมประยุกตตางๆ ดวย Apple Events เปนไปอยางสะดวกงายดายขึ้น
อีกทั้งยังมีโปรแกรม library ที่อนุญาตใหภาษาคําสั่ง Scripting สามารถเรียกชุดคําสั่ง Scripting ที่
ใชอีกภาษาขึ้นมาทํางานได และสงผลใหผูใชสามารถเสริมเอาชุดคําสั่ง Scripting อื่นๆ เขามาในโครงสราง OSA ที่
ตนใชอยูได (ตัวอยางที่ดีสําหรับโครงสรางทางสถาปตยแบบของชุดคําสั่ง Scripting คือ "OLE 2.0 automation
interface) และสามารถเรียกใชคําสั่ง script ในระบบ OSA ของตนผานทางชุดคําสั่ง
Scripting ซึ่งใชภาษาที่ compatible ได
สําหรับผูที่ตองการรายละเอียดเพิ่มเติม
ปจจุบันระบบ OpenDoc อันเปนมาตรฐานใหมสําหรับการ
ประมวลผลแบบ Compound document นี้ไดเริ่มการติดตั้งดําเนินการ และใชงาน
ไปบางแลว แตยังคงเปนไปเฉพาะกลุมผูพัฒนาระบบ (Alpha-testing) และเมื่อใดที่
ระบบดังกลาวสําเร็จเสร็จลงตามประสงค ทราบวาทางทีมงานผูพัฒนาระบบ
OpenDoc มีแผนที่จะเผยแพรผลงานของตน (source code ) โดยผานทางหนวยงาน
ซึ่งเปน กลางสําหรับเหลาบริษัทผูผลิตผลิตภัณฑ
คอมพิวเตอรทั่วไป นั่นคือ หนวยงาน CILCIL
688 Fourth Ave.,
San Fransisco, CA 97118
(408) 974-6549

14. 14
(Component Integration Labs) ซึ่งถาทานผูอานทานใดตองการรายละเอียดมากไปกวาที่นํามากลาวถึงใน
บทความนี้ ก็สามารถติดตอหนวยงาน CIL ไดโดยตรง ตามตําแหนงที่อยูขางลางนี้ :-