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: <1990Aug24.042550.23224@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <21001.650832357@nma.com> <UamjK4S0M2YtM5IlAl@thumper.bellcore.com> <1990Aug23.173253.3063@odin.corp.sgi.com>
Distribution: inet
Date: Fri, 24 Aug 90 04:25:50 GMT

Jonathan Rosenberg says:
>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

I didn't say it was a good place, just that it provided some immediate
functionality and was already providing de facto "mm document standards"
on several platforms.  As applications are optimized to take advantage of
a generalized object manager, the data formats tend toward sanity... at
least in my opinion.

>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

Yes.  The historical solution is to have one popular application's file
format be copied by other applications, which can import its workfiles.
They know about such limitations and when they import a file, deal with 
them.  If you have Lotus, its limitations don't matter.  If you don't,
the application you *do* have knows how to deal with the limitations of 
Lotus's representation, expanding that rep. to its own, richer, format
before using it.  A problem arises in that you would have to know someone
else had Lotus so that your Excel spreadsheet could be sent in Lotus form.
The historical solution to *this*, as we've seen with modems, is to build
systems that support multiple fallback representations if the first-choice
isn't there.  So you might include an Excel spreadsheet as 'first choice',
and a Lotus version as 'last resort', or a passive chart pulled out of the
spreadsheet format by a utility if the user has no spreadsheet at all...

>applications as the generators of document standards: the interchange
>representation is ... not designed as an interchange medium for use among
>heterogeneous systems & applications.

True.  However, as I point out, alternate interpreters of the same data
(other applications) tend to compensate for this, by bending over backwards
to read files built by the de facto standard.  And if you have the de facto
standard application, the file is tailor-made for you anyway.  

This does not solve cross-platform issues, but some interchange formats like
Rich Text Format begin to try.  My thesis is these attempts begin to bridge
the gap and make a short-term, if not long-term, practical solution.

>interpretation above.  This sounds like a "standard" based on people
>using a common set of (versions of) application programs.

Exactly.  The "corporate" definition of "standard"... like it or not,
there are plenty of places where Lotus is THE spreadsheet, and Word is 
THE word processor... their influence will be felt somehow...

>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.  

My question is, and always was, how does that standard representation arise?

** MY POINT **

I submit that the needs of application developers to support their programs
across multiple platforms, to remain compatible with files created by their
old versions, and import and export files to the market leading products,
solve many of the same problems as a standards committee.  To not be aware
of this is a mistake.

Furthermore, applications program *interoperability* is on the rise, and 
the frameworks for this are perfectly suitable to *BE* multimedia mail
or document systems.  If I have a standard representation (good, bad, market
leader, ISO, ANSI, corporate, whatever) for each data type, and an application
of my (my organization's, or my country's) choice that can interpret that type,
and a framework for interlinking the applications such that any one of them
can host a heterogenous "multimedia document", then I do not need any other
architecture to send "multimedia mail".  If you want to be more specific and
say "heterogenous network multimedia mail, world-standardized and guaranteed 
viewable on arbitrary nodes", by all means do so, and more power to you.  But
the world is not waiting on this... good or bad, it is plowing ahead.

** END POINT ***

>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

I don't believe in standardizing "look & feel" at all, although I believe
strongly in standardizing APIs.  There are plenty of toolkits out there
that let you write one source for Open Look/Motif, or PM/Windows, or the
Mac/Windows, and the IEEE has already decided to standardize API and leave
look & feel to personal preferences, where it belongs, and to lawyers, who
get a piece of everything...

>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????

If any 'document' supports inclusion of any other 'document' of any type, 
and the subparts are editable without visibly changing modes, then your
entire system is, from the user's point of view, only one "application".
The set of document types supported will naturally come to be standardized
through specialization.  If I am freed from having to build a pseudo-word-
processor into my spreadsheet or database, then I will come up with a better
and more succinct representation of spreadsheets instead.  

A multimedia mail "standard system" is likely to fail against such 
competition for the same reason that "integrated applications" fail against
their more specialized competitors... people want each tool to do *one thing*,
*well*.  A consequence of doing so, is that data representation tends to
evolve to a complete list of essential elements... and nothing more.  I don't
WANT tabs in my spreadsheet.  If I need them, I will create a word-processing
document, include the spreadsheet, and add the tabs in the WP view.  Then I
can include *that* in another WP document, and I have my tabs.

>> 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?

Usefulness to the *community* that passes the stuff around is not affected.
If you are not part of that community, well, then you have other problems
too.  But in fact it will be a *very long time* before a standards body
gets around to really coming up with acceptable standard script languages
and operating environments.  To the degree is it happening, POSIX and maybe
X/Open are doing it.  But you can get csh for a PC, anyway.  


>>>To stretch the analogy a little, I could claim that X is a graphics mail
>>>standard, since X allows applications to manipulate graphical objects. 
>
>> X does not allow applications to arbitrarily invoke the functions of other
>> applications.
>
>I don't see the relevance of this comment.

Because you didn't get the implication of the arbitrarily-nested 'type'.
What the object management systems are trying to build is an architecture
that makes every piece of work done on a computer into an object, which
encapsulates its own functionality.  Sending data with code that operates
on it, as is often done in NeWS, is a start down this road.

>> 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

A strong prototype useful as a jumping-off point for standards discussion.
Typically a de facto standard, but X itself didn't start out as one.

>>suitable for use as a general-purpose mm mail standard.  Does anyone
>>want to claim otherwise?

ANSI-standard C code, written to require only POSIX system facilities and
the upcoming IEEE-standard GUI API, and straightforward file representations of
the X bytestreams, should move all right:  Any system with a POSIX-compliant
OS, an Xwindows-compliant GUI, and a C compiler could display it.  Not much in
the way of real formatting or interactivity, though...

>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.

Only that there are plenty of people willing to make this sort of compromise,
and it would be better to learn from what they were doing than invent a
totally different mechanism.  I have not yet heard an adequate justification
for this division of effort, which will no doubt cause problems later.

What I see, is the standards people working on data representation, and the
object management people working on function, and precious little thought
about how they are going to come together, with some exceptions you point out.

>> 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

This did not happen with IFF.  In fact, the media types converged strongly.
Problem is, Microsoft, Apple, Sun, IBM, and DEC aren't real interested in
building IFF equivalents for their own systems, although Apple got halfway
there (with resources) and stopped.

>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?

No, but each circle of people who need to exchange MM mail among themselves
does.  Not to the specific application or version like today, but to a
compatible family of same which is created by application portability, 
backward compatibility, and importing/exporting files from the market leader.

>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.

This is heartening.  

Me:
>> Something like NewWave could be a very acceptable mm document standard on 
>> single platforms, 

Jon:
>Something like NewWave could be a very acceptable standard for
>application programs to use to manipulate a mm document standard on single 
>platforms, if ...

Both:
>if the applications used in 'hot-linking' were common
> or minimal enough (like the IFF editors/viewers on the Amiga).

I think there is some conflict in our use of the word "document" - it has
two meanings:  first, as a workfile associated with an application program,
which might be interpreted as a (however inadequate) media type, and second,
as an active collection of such things that are integrated into a 
presentation.  Since things like spreadsheets consist of formulas and data
cells (simpler types), and text documents consist of paragraphs and words
(again, simpler types), in principle the two ideas are the same.  However,
on today's operating systems, they are not treated that way.  When they 
are, there will be a whole new ball game to play.

NRI.RESTON.VA.US!vcerf says:
*I have to agree with your general sense that exchange standards
*for mm objects will have to convey more contextual information
*than one typically finds in a particular application file format.

I agree too.  But that information can be added incrementally through
encapsulation and nesting.

*There is something interesting, though, about what we can see
*happening out there in application land. People who write similar
*applications (e.g. drawing packages) seem to be going to the
*trouble to support import (and sometimes export) in a variety
*of "formats." I don't think what has been done thus far will
*generalize in any particularly nice way because, as you point
*out, these formats were designed for particular applications
*which bring a lot of context to the file which doesn't have
*to be explicitly mentioned in the file itself. 

But it *does* get explicitly mentioned by the compatible applications
which import the files.  If no such capabilities were added, these
applications could hardly compete.  Thus this is a more incremental
approach to defining the 'correct' contextual information.

*I expect, though, that there will be a strong inclination to
*be able to move objects with application-specific content
*around in the mm mail. The best example of the "lack of context"

As I said, the number of available (and usable!) types exceeds the
number of standard types...

*problem is sending ASCII files around with embedded tab
*characters but no indication anywhere as to the correct tab
*settings. ASCII is a wonderfully low level "medium" but even
*ASCII can foul you up, as above. And we all know some of the
*problems with shipping PostScript around...

Yes, problems, problems, but as the standards solidify we will want more
and richer types, and we will generate more such problems.  The problems
will never go away.  My question is, how do we make the decision and
adjustment process a social rather than bureacratic one ?

*I think we will need to accommodate transfer of things like
*TIF, CGM, and other common application formats around, while

Right on.  

*searching for much more general, architecturally sound 
*frameworks for exchange of complex objects.

As I mentioned earlier, this is exactly what the Object Management Group
is trying to do.  And they are not just thinking about 'multimedia mail',
but about much more difficult problems... we don't need two parallel
frameworks.  You don't need NeWS and NewWave alongside each other...
something like NewWave can do the whole job.

zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!lord says:
$Exchange formats seem to me to be only a very small piece of a much
$larger multimedia question.  The question is posed as new technologies
$come on line: new interaction techniques, audio and visual processing,
$new database technologies etc.  As I see it, the unanswered question
$is how all these new parts interact and can be put together.  Talk
$about multimedia documents, and consequently multimedia mail, falls
$right into the middle of these issues.

Couldn't agree more.  The real question is the interaction of *objects*,
and the fact that some objects happen to be displayable to humans and
have specific human-perceptible manipulations is really irrelevant so
far as the architecture is concerned.  At this point it is an API issue.

$Because the functionality of multimedia mail is unknown, an exchange
$format standard at this point faces two choices:
$
$	1. Choose a probably anemic notion of mm functionality and
$	   hold back the state of the practice for the life of the
$	   standard.

Many standards-oriented folks seem to accept this as inevitable.

$	2. Write the standard as a language in which the functional
$	   characteristics of the mail can be described.  Hope that
$	   your language matches the capabilities of emerging mm 
$	   software.

I don't see why that language has to be anything special.  Instead of
inventing a new 4GL mess like SQL, use something object-oriented and
widely accepted like C++.  Soon it will be an ANSI standard anyway.
Or use CLOS, which already is.  Sure it's a mess, but it will work,
and it provides a *mechanism for the definition of new types*.
Add classes for each media type as they are invented, distribute binaries
for each particular machine and window system.

$The second is the better approach, but better still would be to bag
$the exchange format altogether and concetrate directly on mm question
$itself.

I don't care what types we will eventually build.  I only care how to build
types, and I will use whatever tools are available to do so, until I figure
out what the common needs and parameters are... the better and more general
the tool for building types, the faster we will learn, and the better my 
eventual MM system will be.  I guess, in sum, I am arguing for a rapid
prototyping approach - make it easier to build types, and use general-
purpose architectures that will deal with arbitrary types that you have built.

Analogizing it to the user-interface design situation, I would claim that you
learn more, and can do more, with a UI toolkit provided in an object-oriented
language, than you can from using a UIMS of fixed capabilities.  In multimedia,
we will learn more from having a testbed for new types, than from deliberations
of a standards committee.

  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
