craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/20/90)
In existing and proposed systems, I see basically three forms of definition
for new types of multimedia mail/document types, and a quick sketch of the
pros (+) and cons (-) of each:
1. Formal (worldwide, national) standardization
ODA approach
(types are defined in standards meetings)
+ guaranteed compatibility once standard is in place
- long lead-times for new types, negotiation politically motivated
2. Consensus-based (organizational, group) informal standardization
SGML DTD approach, NeWS, IFF, various MM mail systems
(types are defined in a metalanguage or metaformat)
+ types emerge from needs of user groups, obey group boundaries
- types tend to be tied to immediate needs, become obsolete quickly,
hard to guarantee trusted types
3. Application as media type (by platform, vendor, vendor group)
some IFF types, Apple System 7.0, NewWave, OMG initiatives
(types are defined by code in an ordinary programming language)
+ types a 'free' side-effect of applications, integrated with OS
- hard to guarantee trusted types, some applications unsuitable types
each user must have access to same application to interpret type
There may be more. There would seem to be a role for each of the above. In
2 and 3 above, types (applications) can be sent in the mail itself, bringing
up the much-discussed "trust problem".
I think a means of generating and sharing type definitions, independent of
applications, and having systems understand and incorporate them automatically,
is going to be required in 'the' eventual system. In other words, you will be
bundling up a "reader" (storage/transmission-->internal), "writer" (internal->
storage/transmission), and "viewer" (internal-->human-readable/viewable)
programs/functions that would somehow integrate with the rest of the MM
document world - in short, you are providing an encapsulated object.
To do anything with the object other than "view" it, would require a more
elaborated sense of internal structure. Of course, that admits the possibility
of composition from other types, so the structure would have to be recursive.
Any definition of a new type would have to provide at least these three
components. In (1), the reader, writer, and viewer are typically provided
within the scope of a single application. In (2), such definitions are more
separable and may potentially be exchanged across all members of a group,
without having to necessarily exchange the application that generates them.
A standard metalanguage (SGML, PostScript, etc.) may define the form of the
media type and means of displaying it, or interacting with it. This is a
separable (and possibly more secure) level above the operating system. Reader
and writer are standard system facilities, the 'viewer' is the interpreter for
the metalanguage. In (3) that metalanguage is the operating system itself.
Each new application is a new media (document) type. Interactive access is
granted by the window system. Programmed access is granted by the OS or its
"object manager", which brokers messages to objects (applications+documents).
Reader, writer, and viewer are all standard system facilities. There is no
need for a separate 'multimedia' mail or document system.
It seems to me that there is need for all three: the safety, customized
support, and user-group-driven character of a metalanguage approach, the
incremental and practical character of an application-as-object approach,
and the comfort of some international standards.
Ideally, an ISO-standard, incrementally compilable programming language (SGML?
C? CommonLISP?) with an appropriate toolkit or applications framework
(functions to be defined by the user) could provide a standard means of
definition, and some predefined standard types, while a standard OS framework
(like POSIX ?) could provide a standard means of supporting alternate forms
of definition (other languages, fullblown alternate mail systems, etc.). The
key to me seems to be abstracting the notion of a 'media' or 'document' type.
I suggest that the definition of 'object' provided in O-O languages is the
best place to start: encapsulated objects in charge of their own internals,
exporting only a limited set of functions to the world, and having an identity
independent of the means used to store, transmit, or display them - each would
know only how to provide a standard bytestream to a display device, which would
have a means of looking up the appropriate display technique. An SGML DTD is
supposed to be a representation of structure only, and actual compilation to
display/print form is supposed to be accomplished with a separate tool. So
far so good, but a DTD is not exactly a real 'type' the way things work now.
Could someone more familiar with SGML suggest a way this might actually work?
Or how SGML might become more 'object-oriented' in general ?
I think it would be worthwhile to nail down some of these issues before
arguing about what ODA will/won't do... what is the real, eventual, goal ?
Is it written down in any sort of a manifesto, as has been done for object-
oriented databases ? Does the MHEG have anything of this sort ? Have they
released any documents, or have any public discussion ? How is it contacted ?
Do any of them read this group ?
Stirring the pot,
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