Situating MMDD with resp ect to WWW, Portfolio, PREMO, Hyp er-G, ScriptX Sha Xin Wei Novemb er 8, 1994 Abstract We compare the MMDD distributed media system with World Wide Web, Portfolio, Hyp er-G as well as the standards SGML, Hy- Time, PREMO. We also discuss MMDD's relation to the emerging class of scripting environments designed for highly interactive media- richenvironments such as ScriptX. In this note, we assume that the reader is familiar with the design principles underlying the MMDD. See [9]. ASD, Stanford University, [email protected] 1 1 Comparison with World Wide Web and NCSA Mosaic While wehave exp orted some of our corp ora also via World Wide Web [2], [1], WWW and NCSA's design signi cantly di ers from the MMDD's see section 4, and do not serve the MMDD's sp ectrum of media and interactivity. 1 We brie y contrast the two designs to more clearly situate the MMDD: Display Metaphor: NCSA Mosaic, and HTML, are based on a word- pro cessor do cument mo del: text with inlined media "raisins," whichis to o rigid for the sort of interactions the MMDD is designed to supp ort, such as staged video sprites and dynamically de ned comp ound ob jects like "classro om activity" or "historical actor." The MMDD supp orts aworld of co-equal media entities, whichmaybeanything ranging from QuickTime movies, Hyp ercard stacks or Mathematica programs to streams of music or video. Purp ose: WWW and Portfolio were designed to deliver word-pro cessor- like documents, while MMDD is a to olkit designed to provide structures to inform and enrich mo dels or simulations of so cial systems, whichisa much more live, dynamic set of applications. Imagine trying implement SimCity using MS Word. WWW's hyp ertext mo del is the same as MS Word, where the do cuments happ en to span whole continents; this is merely a di erence in degree, not in quality. It would b e just as inecient to try to implement a simulation in WWW. Database Services: Mosaic and WWW have no native design for me- diating database services. CGI's represent a relatively limited stopgap measure via static data forms which do not streamline the real work of cross-database communication, query-generation, mo del management, all of which are uniformly and dynamically handled by the NS dbkit's ob ject-oriented metho ds. The MMDD provides an uniform program- matic interface so that all clients mayinvoke a single language for 1 While we fo cus most of our comparison at the level of the user interfaces, it is imp ortant of course, to distinguish the underlying World Wide Web architecture from the interfaces that happ en to b e written for it. 2 multimedia search, annotation and other database functions for a large variety of database engines. Format. Mosaic requires that its do cuments b e marked up in a xed format { HTML { derived from an older version of SGML. The MMDD, via its ob ject-oriented database structures, requires essentially no as- sumption ab out the internal structure of a blob, yet maintains meta- information and supp orts database functions on the blobs. The data should b e exchanged in the most meaningful terms, eg. an architec- tural building plan with asso ciated information, rather than at the lowest common denominator like a dead bitmap. Sp eci cally, whereas links must b e explicitly written into HTML do c- uments, a lab orious and error-prone op eration which requires that the authors' do cuments b e marked up, MMDD's link-maps are transpar- ently written into indep endent databases by simple user gestures, such as drag-drop under the NS Workspace and Mac front ends. Interface. Mosaic front ends have frozen layout and functionality.A fundamental di erence is that WWW front ends necessarily have xed layout { whereas MMDD front ends' elements buttons, display elds, backgrounds..., maybemoved, reshap ed, even rede ned at any time. Whereas XMosaic and Windows require installation of viewers which must conform to some Mosaic-sp eci c proto cols, MMDD front ends ex- change structured data with ordinary commercial applications familiar to users. Abstractions or meta-data representation. WWW has no notion at all of de ning custom schema or schema editing. By contrast, the MMDD is designed to let authors revise their own schema. MMDD interfaces can b e recon gured in minutes. Services. In contrast to WWW's strategy of providing libraries includ- ing sp ecial-case media viewers on an ad hoc basis, the MMDD's ob- ject architecture provides a rational and exible framework describ ed b elow for integrating any service, not just format conversion, but ar- bitrary functions such as p erforming some calculus or doing a fractal decomp osition of a videoframe. 3 Generality. Finally, WWW may b e viewed as a lowest common denom- inator do cument delivery service which ts inside the MMDD architec- ture. In fact, the MMDD uses a WWW server to its archived media to WWW browsers. Any MMDD pro ject's media can automatically b e made available through WWW. In this context one must realize that merely dumping a le into a WWW server is the relatively easy asp ect of multimedia programming. It takes considerable manual ef- fort to pro duce hyp ermedia, esp ecially in a static data structure like HTML. And even more to create useful indices, search engines, mo d- els and simulations atop the media. To develop interactivemultimedia "kiosks" with such lab or-intensive means mis-allo cates human lab or to tasks which can b e automated in a system like the MMDD. Exam- ple tasks include automatic ltering, automatic link generation from MMDD search ob jects, than explicitly manually pre-fabricating links. 2 Comparison with Portfolio Some of the same di erences are true for Portfolio, to o. The MMDD delib erately deferred issues of user authorization and ver- sioning to Portfolio. Unfortunately Portfolio in its original version was designed around gopher-like le-based description which is to o limited for any sort of exible descriptive systems. Portfolio is sup erceded by WWW. Another di erence is that Portfolio's databases are not designed to communicate with external clients, so it cannot co-exist with infroma- tion retrieval applications written by non-Portfolio programmers. This may b e resolved in the future as they develop and stabilize an API. A third, fundamental di erence is that Portfolio front ends are designed sp eci cally for the Macintosh OS, so there is no way for anyone using other op erating systems to access the information. This is now b eing supplanted by WWW browsers, but see remarks ab ove. 4 3 Comparison with PREMO, HyTime, SGML standards PREMO[8], HyTime [4], SGML [3] are standards, not working systems, but we include them b ecause they represent current standards in the formal de- 2 scription of multimedia including time-based media data. The MMDD do es not prefer one format to another, and in fact is predicated on the exis- tence of a rich space of transformations b etween formats. We discuss these standards from the p oint of view of howwell they serve to describ e the kinds of interactive, media-rich and structure-richenvironments we wish to supp ort. 3.1 SGML SGML probably is the richest description of structured text. Principal limi- tations of SGML include It is designed for one-dimensional character streams. Even multi-linear muscial scores would b e dicult to describ e. SGML in its original form do es not deal with time-based media, or other non-text media 3D animation, mathematical expressions, SGML allows no pro cedural descriptions; it is a meta-level description of data formats rather than a full language. SGML has no abstractions for user interaction. 3.2 HyTime HyTime adds descriptions of time-based media to SGML, and includes no- tions of synchronization, a imp ortant problem in time-based media. However, as p ointed out in [?], there were no pro cedural scripting facilities, nor any mo dels of user interaction. 2 PREMO is the only ISO standard for presentation systems. 5 3.3 PREMO We feel that the MMDD would interpret the PREMO scheme b ecause it is already layered to decouple data, mo del and presentation [9]. As mentioned in [HyTime],however, it is not clear howwell HyTime or PREMO match the expressivity of applications like Apple Hyp ercard, Oracle Media Ob jects, or emerging frameworks like Kaleida's ScriptX or Taligent's time-based media. 4 Comparison with Hyp er-G Hyp er-G [5] at the University of Graz, Austria, shares design tenets with our work. They also decouple data, format, and hyp ermedia link structure. In fact they have a link server which seems to b e more p owerful than our link database. Signi cant di erences are Hyp er-G is built around a traditional metaphor of do cuments with emb edded links. It is essentially a unix/X windows system and thus, do es not integrate with commercial universe of p ersonal computer applications. As such, Hyp er-G deals with a set of environments and users complementary to those served by MMDD. Hyp er-G has no scripting framework of GUI's, whereas MMDD front ends use Hyp ertalk { a p opular scripting language and AppleScript on the Macintosh, and InterfaceBuilder/Pro jectBuilder on NS. 5 Comparison with interface scripting frame- works The MMDD was designed to supp ort the creation of highly interactive media- rich simulations.