Jump to content

OpenDoc: Difference between revisions

From EDM2
← Older editNewer edit →
Ak120 (talk | contribs)
35,819 edits
Ak120 (talk | contribs)
35,819 edits
mNo edit summary
Line 5: Line 5:


==Technology==
==Technology==
Basically an OpenDoc compound document is comprised of modules known as "Parts" that each have its own control program that is referred to as an "Editor". An OpenDoc Part can be anything a normal application would offer, eg a spreadsheet Part, a text Part, a database Part and so on, each Part can not only coexist with other parts in the compound document but they can also nest inside each other. When you open a compound document, you are effectively using a collection of Editors rather than a single program.  
Basically an OpenDoc compound document consists of modules known as "Parts" that each have its own control program that is referred to as an "Editor". An OpenDoc Part can be anything a normal application would offer, e.g. a spreadsheet Part, a text Part, a database Part and so on. Each Part can not only coexist with other parts in the compound document, but they can also nest inside each other. When you open a compound document, you are effectively using a collection of Editors rather than a single program.  


If no other storage format is requested or specified by the Editor the data is stored in a meta-format called '''Bento''', that gives each Editor or Part a storage object of its own called "Storage Unit" that contains a list of properties inside it making it look like a file directory to the end user, in turn each Storage Unit is contained inside a list of SU's called Draft but in addition to operating as a sort of an index for Storage units contained inside the handles the householding of file reads and writes, but changes to a Storage Unit are not saved wholesale by a Draft but rather only the changes at each save, which in turn opens up the possibility of an almost infinite undo/redo operations.
If no other storage format is requested or specified by the Editor the data is stored in a meta-format called '''Bento''', that gives each Editor or Part a storage object of its own called "Storage Unit" that contains a list of properties inside it making it look like a file directory to the end user, in turn each Storage Unit is contained inside a list of SU's called Draft but in addition to operating as a sort of index for Storage units contained inside the handles the householding of file reads and writes. Changes to a Storage Unit are not saved wholesale by a Draft, but rather only the changes at each save, which in turn opens up the possibility of an almost infinite undo/redo operations.


OpenDoc received quite a bit of criticism for being overly complex for what it does. After the discontinuation of OS/2, IBM promised to open source the whole thing but that never happened, according to rumours [[Apple]] prevented them from doing so.
OpenDoc received quite a bit of criticism for being overly complex for what it does. After the discontinuation of OS/2, IBM promised to open source the whole thing but that never happened. According to rumours, [[Apple]] prevented them from doing so.


;Collaborative editing
;Collaborative editing
But there is another aspect to a compound document system and that is the possibility of collaborative editing, OpenDoc supports more that one person "owning" each document so that more than one person can work on each document at a time if the application supports it, this is more or less inherent with the external material embedded into another doucement nature of a compound document. But more interestingly even if the application in question does not support it directly
But there is another aspect to a compound document system and that is the possibility of collaborative editing, OpenDoc supports more than one person "owning" each document so that more than one person can work on each document at a time if the application supports it, this is more or less inherent with the external material embedded into another document nature of a compound document. But more interestingly, even if the application in question does not support it directly
more than one person can work on the same document as long as they are not working inside the same container, e.g. a graphics designer can continue to work on the graphics inside one container while the author of the text or code can carry on working inside his container.
more than one person can work on the same document as long as they are not working inside the same container, e.g. a graphics designer can continue to work on the graphics inside one container while the author of the text or code can carry on working inside his container.


While we do have collaborative document systems today with sundry web based services they all require access to a centralised and specialised document servers while OpenDoc and similar systems allow this by default and without the need for external mechanisms of any kind.
While we do have collaborative document systems today with sundry web based services they all require access to a centralised and specialised document servers, while OpenDoc and similar systems allow this by default and without the need for external mechanisms of any kind.


==History==
==History==
Line 25: Line 25:
* [[Apple OpenDoc]]
* [[Apple OpenDoc]]
* Novell version of OpenDoc (Contains early version of SOM for Windows)
* Novell version of OpenDoc (Contains early version of SOM for Windows)
* [[IBM OpenDoc for AIX]] - Relies on SOMTK SDK (not included) - OpenDoc.tar.Z.
* [[IBM OpenDoc for AIX]] - Relies on SOMTK SDK (not included) - OpenDoc.tar.Z
* [[IBM OpenDoc for OS/2]]
* [[IBM OpenDoc for OS/2]]
* IBM OpenDoc for Windows NT and Windows 95 - With sources OpenDoc, Bento and IBM’s sample Parts
* IBM OpenDoc for Windows NT and Windows 95 - With sources OpenDoc, Bento and IBM’s sample Parts
Line 42: Line 42:
* R. Tycast: ''[[OpenDoc Technology: Basic Concepts]]'' - (Mar 1994)
* R. Tycast: ''[[OpenDoc Technology: Basic Concepts]]'' - (Mar 1994)
* [[Elizabeth Ann Dykstra-Erickson]]; [[Dave Curbow]]: ''[http://rdcurbow.net/David/Articles/ODUserStudies.pdf Role of User Studies in Design of OpenDoc®]''
* [[Elizabeth Ann Dykstra-Erickson]]; [[Dave Curbow]]: ''[http://rdcurbow.net/David/Articles/ODUserStudies.pdf Role of User Studies in Design of OpenDoc®]''
* [[Ralph M. Pipitone]]: ''[https://web.archive.org/web/19980120020159/http://pscc.dfw.ibm.com/psmag/SEPT95/pipitone.htm OpenDoc and Human-Computer Interaction]'' - [[Personal Systems Magazine]], Sep/Oct 1995
* [[Ralph M. Pipitone]]: ''[https://web.archive.org/web/19980120020159/http://pscc.dfw.ibm.com/psmag/SEPT95/pipitone.htm OpenDoc and Human-Computer Interaction]'' - [[Personal Systems Magazine]], Sep/Oct 1995
* Scott Tooker and Rodney Cole: [https://web.archive.org/web/20100611074615/http://maxwell.ucdavis.edu/~cole/papers/scott_fie.pdf Using OpenDoc to create low-cost physics simulation tools for secondary and higher education] - (Nov 1996)
* Scott Tooker and Rodney Cole: [https://web.archive.org/web/20100611074615/http://maxwell.ucdavis.edu/~cole/papers/scott_fie.pdf Using OpenDoc to create low-cost physics simulation tools for secondary and higher education] - (Nov 1996)
* Elizabeth Dykstra-Erickson, Dave Curbow, Geoff Schuller and [[Kurt Piersol]]:[http://www.rdcurbow.net/David/Articles/ODCollaboration.pdf Collaborative Aspects of OpenDoc]
* Elizabeth Dykstra-Erickson, Dave Curbow, Geoff Schuller, Kurt Piersol:[http://www.rdcurbow.net/David/Articles/ODCollaboration.pdf Collaborative Aspects of OpenDoc]
*Dave Curbow: [http://www.rdcurbow.net/David/Articles/ODLessons.pdf Lessons learned from OpenDoc]
*Dave Curbow: [http://www.rdcurbow.net/David/Articles/ODLessons.pdf Lessons learned from OpenDoc]
*Elizabeth Dykstra-Erickson; Dave Curbow: [http://www.rdcurbow.net/David/Articles/DesigningODHI.pdf Designing the OpenDoc® Human Interface]
*Elizabeth Dykstra-Erickson; Dave Curbow: [http://www.rdcurbow.net/David/Articles/DesigningODHI.pdf Designing the OpenDoc® Human Interface]
Line 50: Line 50:
;Bento
;Bento
* [[Kirk Searls]]: ''[[Bento Technology]]'' (Mar 1994)
* [[Kirk Searls]]: ''[[Bento Technology]]'' (Mar 1994)
* [http://ei.cs.vt.edu/~mm/txts/Bento-brief.txt Bento Brief] - CILabs (Sep 1995)
* [http://ei.cs.vt.edu/~mm/txts/Bento-brief.txt Bento Brief] - CILabs (Sep 1995)
* [http://ei.cs.vt.edu/~mm/txts/Bento-design.txt Bento Design Overview] - CILabs (1995)
* [http://ei.cs.vt.edu/~mm/txts/Bento-design.txt Bento Design Overview] - CILabs (1995)
* [[Matt Timmermans]]: [[SGML and OpenDoc - Bento]] (Sep 1995)
* [[Matt Timmermans]]: [[SGML and OpenDoc - Bento]] (Sep 1995)
Line 68: Line 68:
* Tycast: ''[[Understanding How OpenDoc "Ticks" Using Trace and Debug Tools]]'' (Aug 1995)
* Tycast: ''[[Understanding How OpenDoc "Ticks" Using Trace and Debug Tools]]'' (Aug 1995)
* Gregg Williams: ''OpenDoc and Java Beans'' (1997)
* Gregg Williams: ''OpenDoc and Java Beans'' (1997)
* [http://static.userland.com/userLandDiscussArchive/msg021157.html Bento and OpenDoc] by David McCusker (Coments about IronDoc) (2000)
* [http://static.userland.com/userLandDiscussArchive/msg021157.html Bento and OpenDoc] by David McCusker (Comments about IronDoc) (2000)


;Related patents
;Related patents

Revision as of 16:37, 17 December 2022

OpenDoc was a collaborative effort between Apple Computer, IBM, WordPerfect Corp. (later Novell), Sun Microsystems, XSoft and Taligent to create a vendor independent, open standard for compound documents.

Its development was later taken over by a company called Component Integration Laboratories (CI Labs) that was owned by Apple, IBM and Justsystem. For a time CIL marketed an OpenDoc/CORBA solution for Java under the Live Objects brand. The lack of sales meant that CI Labs was dissolved in 1998 and there was talk about open sourcing the code for OpenDoc and other CI Labs products but for legal reasons that never happened.

Technology

Basically an OpenDoc compound document consists of modules known as "Parts" that each have its own control program that is referred to as an "Editor". An OpenDoc Part can be anything a normal application would offer, e.g. a spreadsheet Part, a text Part, a database Part and so on. Each Part can not only coexist with other parts in the compound document, but they can also nest inside each other. When you open a compound document, you are effectively using a collection of Editors rather than a single program.

If no other storage format is requested or specified by the Editor the data is stored in a meta-format called Bento, that gives each Editor or Part a storage object of its own called "Storage Unit" that contains a list of properties inside it making it look like a file directory to the end user, in turn each Storage Unit is contained inside a list of SU's called Draft but in addition to operating as a sort of index for Storage units contained inside the handles the householding of file reads and writes. Changes to a Storage Unit are not saved wholesale by a Draft, but rather only the changes at each save, which in turn opens up the possibility of an almost infinite undo/redo operations.

OpenDoc received quite a bit of criticism for being overly complex for what it does. After the discontinuation of OS/2, IBM promised to open source the whole thing but that never happened. According to rumours, Apple prevented them from doing so.

Collaborative editing

But there is another aspect to a compound document system and that is the possibility of collaborative editing, OpenDoc supports more than one person "owning" each document so that more than one person can work on each document at a time if the application supports it, this is more or less inherent with the external material embedded into another document nature of a compound document. But more interestingly, even if the application in question does not support it directly more than one person can work on the same document as long as they are not working inside the same container, e.g. a graphics designer can continue to work on the graphics inside one container while the author of the text or code can carry on working inside his container.

While we do have collaborative document systems today with sundry web based services they all require access to a centralised and specialised document servers, while OpenDoc and similar systems allow this by default and without the need for external mechanisms of any kind.

History

While OpenDoc is sometimes presented as an answer to Microsoft's Object Linking and Embedding (OLE) technologies it actually has a history predating Microsoft's introduction of OLE and the rather weak COM model, OpenDoc's ancestry lies with the Xerox Star system which offered a rudimentary compound document system, but a number of the original OpenDoc team at Apple had worked for Xerox on the Star prior to joining Apple. What spurred them into action was the huge interest generated by the extensible objects available for the Oberon operating system and the compound documents that went with that idea, those two technologies were a hot topic in the early nineties.

The research into the Oberon extensible/compound document system eventually resulted in the Oberon/F system later commercialised under the BlackBox Oberon name, but further development of that system was hampered when Microsoft poached more or less the entire BlackBox development team from Oberon Microsystems. Noticeably the BlackBox system is easier to use and develop for, much simpler and faster than OpenDoc if not as language independent.

Developer Frameworks

  • Apple OpenDoc
  • Novell version of OpenDoc (Contains early version of SOM for Windows)
  • IBM OpenDoc for AIX - Relies on SOMTK SDK (not included) - OpenDoc.tar.Z
  • IBM OpenDoc for OS/2
  • IBM OpenDoc for Windows NT and Windows 95 - With sources OpenDoc, Bento and IBM’s sample Parts

Developer Tools

  • IBM PartMeister

Publications

Books

  • Feiler: Essential OpenDoc – Addison-Wesley 1996, ISBN 0-201-47958-3
  • Bart Jacob, Henri Jubin: Part Development for OpenDoc - Prentice Hall 1997, ISBN 0-13-263286-1

Articles

Bento
Open Scripting Architecture (OSA)
More Articles
Related patents
Marketing material

Software based on OpenDoc

  • Lotus Components
  • WebPainter for OpenDoc
  • Mesa 2 - Spreadsheet

Links

  • Greg Maletic - 1995 Apple Product Marketing Manager for OpenDoc.
Related projects
Retrieved from "https://www.edm2.com/index.php?title=OpenDoc&oldid=79622"