Newsgroups: comp.mail.multi-media Path: utzoo!utgpu!craig From: craig@gpu.utcs.utoronto.ca (Craig Hubley) Subject: Re: Multi-media mail standards; Forw: Use of ODA in the Internet Message-ID: <1990Aug22.051724.4616@gpu.utcs.utoronto.ca> Organization: Craig Hubley & Associates References: <1990Aug19.195257.13157@gpu.utcs.utoronto.ca> Distribution: inet Date: Wed, 22 Aug 90 05:17:24 GMT >THUMPER.BELLCORE.COM!jxr (Jonathan Rosenberg) says: >Craig Hubley says: >> body of work that it didn't cover. I mean the current efforts to standardize >> "Object Management", including tangible media objects, that are happening in >> the microcomputer world. It seems very likely that this work will have a >> major effect on the form of any real working standard, as microcomputers >> are by far the most likely terminals for any MM document or mail system. >>I would like to start a debate going on the advantages/disadvantages of this >> approach to multimedia documents. > >Well, you asked for it ... > >I must admit to being quite confused about the relationship of the kinds >of standards/architectures you discussed in your message & a mm mail >document standard. It is two more or less separate ideas that are converging very strongly in practice, and have converged completely in some precedent-setting systems. TIEING UP TYPES Most of the debate over MM mail/documents seems to be around the definition of media types, and creation of a flexible architecture to support arbitrary types, including provisions for time-synchronized media (video, music) alongside browsable media (text, still pictures...). >It is clear that in order to be usable as a mail standard, a document >architecture must have a specified interchange format (also known as a >datastream). I.e., the arch must specify the actual bits that are to be >placed into the message to represent the document. The efforts I describe define this as the user's work file format (e.g a Lotus 1-2-3 spreadsheet in binary format) or a 'hot link' to such a file. The list of operations is the complete user interface of the application program (e.g. Lotus 1-2-3) itself. As such, it is defined not in PostScript or SGML but in a standard programming language, compiled for a given platform. The application itself may support an architecture-neutral interchange format for workfiles across platforms, but this is not necessary. So not all types of 'objects' are necessarily portable across all platforms. There is also the question of availability of the application on each receiver's platform. An organizational standard might specify "everyone will have Lotus, Word Perfect, and Oracle available", thereby enabling 'multimedia' documents (that consist of, say, Word Perfect documents that include Oracle tables and Lotus spreadsheet views) to be freely passed around. MEDIA TYPES On a multitasking, multimedia machine like the Amiga, this sort of an architecture already more or less exists, although it is not integrated with an embedded-editor protocol or full hypermedia system. Programmability is provided through AREXX, which Amiga applications support to enable remote control. Basic media forms like music and graphics are defined by IFF, the Interchange File Format. IFF started as a set of workfile formats for graphic programs, defining types like 640x480 pictures or sound bites, but now more complex forms like animations or 3D models are typically defined more by application programs, and adopted by the community of users, and often by new programs that support the IFF formats defined by the trailblazers. This is similar to the way every PC spreadsheet converts to/from Lotus files. MORE COMPLEX MEDIA As PCs and Macs acquire multimedia and multitasking abilities, it seems logical that minimal formats for exchange of spreadsheets, relational tables, etc., will develop, paralleling those for exchange of basic media objects. The Mac already has a prototype of such a system, with its "resource fork". The application program decides where and when each resource is used in the presentation, but the resource itself is interchangeable with others of its type - the application is simply a framework for the presentation of resources. >Now, if I understand the standards you have described (and, I may not >understand them correctly), they are descriptions of application program >interfaces that allow executing processes to manipulate mm objects. Not quite. Executing processes can manipulate ANY OTHER DOCUMENT THROUGH ITS ASSOCIATED APPLICATION, just as if they were the human user, and often with additional capabilities. The set of MM object types is not fixed, in effect a new type is defined every time a new application is built, and a new object of that type is created every time someone builds a document using it. So if I use an animation program and create the animation "Bedtime for Bonzo", any other program can run it/change it/etc. But this is only the first part. Some of these systems also define an embedded-viewing protocol so that all of these parts can be presented as part of a single hypermedia document. That document's "architecture" need not be standardized, as ANY APPLICATION can support the inclusion of such multimedia bits and pieces. In other words, I can include paragraphs formatted in WordPerfect in my Lotus spreadsheet, just as easily as vice versa. And changes are propagated properly. There is now only an organizational need for standards. The technical barriers are gone. >This is obviously an important kind of standard, but I fail to see how >one of these standards can be said to be a "mmm document standard". To Each application is its own, and it is true that none is really standard. But it would hardly matter, as the capabilities of each application would meld into a single whole with one set of functions available from anywhere. There is a set of types that continues to grow, and it is true that at any given point in time there will be more available types than standard types. >be useful, one would have to define an interchange format for each >standard. Now, this might be possible for any one of these standards, >but given the original impetus for them (application program tool >kits/standards), I'm not sure they lend themselves to mail standards. Consider the Unix mail community. People have few qualms about mailing files incomprehensible without rot13, UUencode, TAR, SH, csh, troff, etc.. In effect the "standard" has emerged from constant use, and the usefulness of the system is not drastically reduced by the proliferation of types. The ones that have tended to survive are those really represent a single kind of problem. >To stretch the analogy a little, I could claim that X is a graphics mail >standard, since X allows applications to manipulate graphical objects. >But, I hope no one would make this claim. X does not allow applications to arbitrarily invoke the functions of other applications. However, media objects as defined by the X protocols, plus C or other programs written to present these to the user, could be said to constitute a proto-standard. Similarly, a lot of people with bandwidth to burn mail HyperCard stacks to each other... >Am I way off base here? Or, are you suggesting that we start with (one >of) these standards & come up with an appropriate interchange format for >them. Perhaps. I would like to make a list of desirable minimal interchange formats (types we would like to see standardized) and perhaps identify likely existing candidates for each. Industry groups are already working on sound bites, musical notation, animations, video frames, relational tables, spreadsheets, etc., etc., and it would seem that all we need to do is have a list of such widely-recognized minimal standard interchange formats. We could write and exchange very minimal readers/writers/interpreters for them, work on new and more widely-compatible interchange formats, or define prototype architectures to simply store and transmit them, and invoke their functions. This is a very bottom-up approach to the problem, but in fact it is happening today, and people are sending "multimedia mail" in HyperCard and other formats, but no concerted effort seems to be made at building a set of interchange formats that arises from practice. Something like NewWave could be a very acceptable mm document standard on single platforms, if the applications used in 'hot-linking' were common or minimal enough (like the IFF editors/viewers on the Amiga). It remains to define a rational set of foundation types, and interchange standards across platforms. NewWave itself might accomplish much of this by bridging DOS and Unix, and the OMG is definitely set to do so across the platforms of the seventy-odd companies that have joined. Now, they might use ODA as their basic set of types, providing minimal 'applications' to deal with these, but their means of building new types would be very different. For this community, the questions should be: "which types should be defined by standards body fiat, which by de facto standards, which by negotiation of an interchange format ?", "how should we be defining new types ?", and "will people accept a closed system where capabilities cannot be seamlessly extended by user-group agreement ?" Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig -- Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig