🚀 go-pugleaf

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
particular type.  Because CDA was designed by DEC to support the
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.

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.

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

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.

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

Standards like the ISO standard for exchanging computer tape at 800
bits per inch started out as the IBM tape drive product.  Because IBM
tape drives were out there, there were a lot of them, and they worked,
other vendors made products that would work with the IBM written tapes.
Eventually, the characteristics of the IBM product were written
down as a standard.  The de facto capabilities of the IBM product,
and its limitations, became the stanadard because that was the
easiest thing to do.  The test for compatibility was, "Can a tape
written on drive X be read by an IBM drive?"
By contrast, other standards, like the Intelligent Peripheral
Interface (IPI) represent technological combinations which were put
together for the first time in a committee, and attempted to include
ideas from many different sources.  There was no reference
implementation, and each vendor worked on implementations which would
conform to the document, not to some reference implementation.  Not every
implementation of IPI provides all the features of the documented standard.

So both approaches to standards development have historical precedent.
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
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.

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.
Marvin Sirbu
CMU