Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!THUMPER.BELLCORE.COM!jxr From: jxr@THUMPER.BELLCORE.COM (Jonathan Rosenberg) Newsgroups: comp.mail.multi-media Subject: Re: Multi-media mail standards Message-ID: Date: 22 Aug 90 18:22:58 GMT References: <1990Aug22.051724.4616@gpu.utcs.utoronto.ca> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 152 Date: 22 Aug 90 05:17:24 GMT From: news-server.csri.toronto.edu!utgpu!craig@rutgers.edu (Craig Hubley) Organization: Craig Hubley & Associates Subject: Re: Multi-media mail standards; Forw: Use of ODA in the Internet To: mmm-people@venera.isi.edu >>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. If I understand you correctly, you're suggesting that the interchange format for such applications is just whatever file format the application happens to use. If so, then this seems like a bad place to start looking for mm document standards (for mail or otherwise). In particular, this file format is particular to its generating application (since that's what it's used for) and the format will, in general, only include such information as is necessary for the application's execution. So, for example, if the application supports only a single fixed margin for text, then presumably the format will not include any information about margins, since that information is embedded in the application. And, that's exactly the problem with considering such applications as the generators of document standards: the interchange representation is peculiar to the application (and, sometimes, its implementation) and not designed as an interchange medium for use among heterogeneous systems & applications. > 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. Arggghhh ... now, I feel more certain that I was correct in my interpretation above. This sounds like a "standard" based on people using a common set of (versions of) application programs. I humbly submit that your examples are at the wrong level: you're describing applications that may be suitable for manipulating a document in some standard representation. I admit that it may be worthwhile to standardize on aspects of some of these applications (e.g., look & feel, application program interface). But, these standardizations are not the same as standardizing on a document architecture suitable for interchange. > . . . > 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. Huh???? > . . . > 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. Gee, I would argue that usefulness IS affected by the use of these encoding techniques. What do you think happens when a piece of mail that requires csh ends up on a PC or an IBM mainframe? >>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. I don't see the relevance of this comment. > 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. It may be a "proto-standard" (whatever that is), but it's in no way suitable for use as a general-purpose mm mail standard. Does anyone want to claim otherwise? > Similarly, a lot of people with bandwidth to burn mail HyperCard stacks to each other... Sure -- and if we all agree to only use HyperCard to edit/present mm documents, this would work just fine. But, given the heterogeneous world that exists I fail to see the relevance of this point. >>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 sounds like it would result in a bunch of unrelated media representations (we already have that situation). How, in your approach, would we ever end up with a means for integrating multiple media into a single "document"? Do we all need to agree on a finite set of specific applications to perform this integration? > 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. Well, that just ain't so. For example, ODA does, in fact, make use of several such formats. The geometric graphics format (CGM) and the raster graphics formats (Group 3 & 4) are based on (very) widely-used formats. These formats did arise in 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). I disagree (as you might have guessed by now). I would rephrase your statement to say Something like NewWave could be a very acceptable standard for application programs to use to manipulate a mm document standard on single platforms, if ... > . . . Comments encouraged. JR