🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.mail.multi-media
Article #141

Re: Multi-media mail standards

#141
From: Jonathan Rosenberg
Date: Wed, 22 Aug 1990 18:22
152 lines
7951 bytes
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
Technical Details
Message-ID: <Eaogq220M2Y14A8VtE@thumper.bellcore.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!THUMPER.BELLCORE.COM!jxr
References: <1990Aug22.051724.4616@gpu.utcs.utoronto.ca>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <Eaogq220M2Y14A8VtE@thumper.bellcore.com>
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