Newsgroups: comp.mail.multi-media
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: the debate between Jon and Craig
Message-ID: <1990Aug24.063839.29977@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <kap9APS00io2Q0uls1@andrew.cmu.edu>
Distribution: inet
Date: Fri, 24 Aug 90 06:38:39 GMT

ANDREW.CMU.EDU!ms6b+ (Marvin Sirbu) says:
>Jonathon's original list of possible starting points for document standards
>included CDA from DEC.  In fact, DEC provides for exactly the notion that
>Craig describes of sending along application code, or the name of the
>appropriate application to use, in order to view/edit/manipulate a

I don't know much about CDA, but from this information it would seem that
CDA plans to take a pretty general object-management approach.  However, I
am not sure if its philosophy is that there should be only *one* object-
management scheme, and that all resources should be accessed that way.
Now that DEC is releasing its Trellis object-oriented system, perhaps some
framework will be provided there for building CDA-compatible types... perhaps
the DEC object database itself will provide this capability using Trellis...
this would be interesting, because the line between "media" and "application"
would be blurred out of existence.  As I think it should be.

>DEC product family, (only two hardware architectures) DEC can assume
>that the requisite applications are available throughout the universe
>DEC intended CDA to operate in.

This is similar to the use of tar, troff, csh files and the like on Unix.

>The idea of using some widely available program and its data file as a
>component of multimedia mail has several defects:
>1) you are limited to the capabilities of the particular software package
>in terms of that type.  If Lotus 1.0 is your standard for spreadsheets,
>they you can't send three dimensional spreadsheets.  Jon made a similar
>point using the example of margins.

Yes, the best you can do is to send three dimensional spreadsheets in Wingz 
format, and provide a fallback Lotus version, or rely on an intermediary
(which knows what the receiver can do) to translate one to the other.
Lotus isn't really your 'standard' (in fact any available translation from
one format to another could be invoked) but if you go beyond its capabilities
you risk translation not being available.  Such a system makes it possible
to move incrementally towards an interchange standard, however.  At first
it is provided as the fallback, but as more and more applications support
it, it becomes the first rather than the last resort.  In effect, it moves
from supporting a N**2 1-1 translations to supporting N many-1 translations.
But N is not very large in the beginning, and as it grows, so does support
for the interchange standard.  There is also the potential for chained
translations, say Wingz->Excel->Works or something, but of course the longer
these get the more information you are likely to lose.  A generalized 
conversion scheme like that in C++ would be useful.  Use C++, and you'd get
it for free... :)

>2)  you are limited to the platforms which support the standard application.
>or at least support the standard application's file format.  (I can send
>a Lotus file to a Mac and read it with Excel because the Lotus file format
>is widely read.)

Yes, this is potentially very debilitating.  I am relying on the application
software vendors to make their systems available on my platform, or on other
vendors to build systems compatible with their formats.  This is a slow
process - *almost* as slow as standard-setting.  However, there are some
companies out there, like WordPerfect or Oracle, that are hell-bent to
get themselves on practically any platform that can run the product... that
becomes a more supportable strategy under an object management system,
since you may become the de facto representation standard for your doc-type.

>It also has some advantages.  Now, the fact is that IBM PCs are so
>widespread that a lot of useful multimedia interchange could
>conceivably take place just by sending around combinations of Word
>Perfect + Lotus files.  And those who are anxious to get some real
>multimedia going now, but don't care about universality and generality
>can get started that way.

I wouldn't say I don't care, but I sure think there are some issues to work
out that don't require universality or generality of types or of platforms...

Universality and generality are always relative, anyway.  I haven't heard
anyone talking about virtual reality interchange standards, or multimedia
document systems that will run on an Apple II.

>By contrast, if you believe that
>1) we need standards that support interchange with machines that Lotus doesn't
>run on (yet...); or

Can we build such standards, and perform such interchanges, while still letting
PC users swap around their spreadsheets ?  Will ODA let us encapsulate Lotus, 
with all its pluses and minuses, as an ODA-format type, that can be included 
in ODA documents, and provide a means of getting the list of types in the
document so that mailers, forwarders, and receivers can perform translations,
fallbacks, or rejections ?

>2) if we look at the functionality of lots of spreadsheet programs (substitute
>text, graphics, music, etc.) we can define a file format which supports
>the union of all the capabilities in all of them,
>then, you try and develop or extend something like ODA.

I agree this should be done, but no standards committee can do it correctly, 
once and for all.  A more incremental process of type design, construction,
and testing needs to be supported, and if you always wait for a world-standard
need for a new type to develop before building it, your system runs the risk
of irrelevance.

>Standards like the ISO standard for exchanging computer tape at 800
>bits per inch started out as the IBM tape drive product.  Because IBM
>...
>Interface (IPI) represent technological combinations which were put
>together for the first time in a committee, and attempted to include
>...
>So both approaches to standards development have historical precedent.

Good examples!  But can we find a precedent for an extensible standard ? That 
is, where the means of extending its capabilities were well-defined ? Ethernet 
packet types might be an example.  The beauty of Ethernets is that dozens of
machines can all inhabit the same Ethernet, all speaking totally different
protocols to each other.  As the world standards bodies hammer away on a 
single OSI protocol that they can speak to each other, they can still speak
TCP-IP, DECnet, XNS, or whatever else you like... and gateways can translate
one into the other.  These systems are useful today, and the same framework
will be able to support the OSI protocols incrementally as they are developed.
But the migration will be slow.  Even if you had a standard spreadsheet type
tomorrow, Lotus would take a long time supporting it.  In fact, they might
not bother until they were supplanted as the de facto interchange format...

>However, it is worth pointing out that there has been a relative decline
>in the success rate of de facto standards, and a marked increase in standards
>designed by committees over the last 15 years.  While I am not sure I can

How about their success rate ?

>explain why fully, I believe it is because of the increasing heterogeneity
>of information technology hardware and users.  There are no firms
>with the dominating power of an IBM or AT&T of the 1960s, nor, arguably,
>is even the IBM PC such a dominant de facto architecture.  Thus, it
>is not realistic to expect a standard developed around "popular" applications
>to become a sufficient de facto standard to really be universal.

One could argue that industry groups like X/Open, OSF, and Unix International,
plus some dominating players like Microsoft, have taken over this kind of role.
Of course, often these are just the old players in new disguises.  But
paralleling the growth of diversity in hardware and users is increasing
recognition among the players that they do better by voluntarily cooperating.
This has been proven in niche markets (Amiga developers supported IFF and AREXX
because they would have found it hard to sell their product at all without
them) but as competition in major markets increases, so does the pressure to
cooperate, if only to define spheres of influence.

>On the other hand, standards processes are so slow, that you can do an
>awful lot of useful work based on the other approach while standards
>are being developed -- as, evidently, DEC has decided in bringing out CDA.

DEC is also thinking more generally about the object management problem -
that is, they are building an object database and have joined the OMG...
they may be thinking of CDA as a prototype for an even more general system
that would go beyond 'documents' into arbitrary software objects, including
those with types defined fully by a user and shared by a group - a basic
capability of object databases.  This would be something to watch for...
then you would be able to support the user-defined, corporate-standard and 
world-standard types alongside each other in the same system... so more
functionality is available within a tighter circle, but less is shared in
common as you move outward, and in the outermost circle the only guaranteed
means of exchange is the relatively small set of world standard types.
As these increase in number, the lowest common denominator system expands,
and slowly the user-defined types are replaced... but only incrementally.
And without ever losing their functionality.  Can I have my cake and eat it, 
too ?

  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
