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> <Yao0Eku0M2Y1066oBq@thumper.bellcore.com>
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
