pem-dev
[Top] [All Lists]

Re: MIME vs. HGML vs. OLE/DDE

1995-02-06 11:13:00
Ned, I may be about to ask a dumb question, but could you help me understand
the relationship between MIME and other approaches to a dynamic interface to
various objects, e.g., HGML?

I assume you mean HTML here... I don't know what HGML is.

Let me explain what I mean.

My MIME system allows me to include attachments to an e-mail message, but in
order to examine or "play" those attachments I have to individually select 
them
and execute the appropriate "viewer". I don't know whether or not MPEG 
includes
a sound capability or not, but assuming it doesn't, I couldn't synchronize an
audio segment with the MPEG image to lip-synch with a video of a person, on 
the
waves crashing on a beach, etc.

This isn't really true. For one thing, MIME already has the concept of
"parallel" parts that are supposed to be displayed/read/played/imaged/viewd
simultaneously. See the definition of multipart/parallel in RFC1521 for
details.

For another, the need to individually select to view is an attribute of the
mail system you happen to be using, not an intrinsic characteristic of MIME
itself. All sorts of viewing models are possible, even for mixed groups
of attachments with no parallism specified.

Now, it is true that MIME doesn't have a means to precisely synchronize the
rendition of multiple parts -- there is no multipart type for that right now.
However, there is already work underway to do this sort of thing in the SGML
community. This is positional in nature rather than temporal, but there's no
reason it could not be extended.

Likewise, I can include a spreadsheet in my MIME object, but I have no way of
linking the current values of that spreadsheet back into my annual report 
text.

In other words, MIME doesn't support something like Window's Object Linking
Environment or Dynamic Data Environment, nor does it support HGML's hypertext
links to another object (and back up the stack again.) Of course it does
facilitate these operations by allowing the software to be distributed, but it
doesn't support any kind of triggering mechanims or any direct form of
embedding, so far as I know.

This is also incorrect. MIME provides the ability to identify each part of a
message separate and build references to it. All that's needed is the ability
to put such references into data objects, and there is work underway to define
URL syntaxes for this sort of thing. Once this is done you can use HTML to
build the framework around the various parts.

References to subparts of parts are trickier, of course, and depend on the
nature of the data involved. I don't know of anyone working on this aspect
of the problem right now.

Is my understanding correct, first of all, at least with respect to current
MIME products and standards, and if so, is anyone giving any thought to
extensions along these lines?

See above. Note that all MIME really has to do is provide the reference
mechanism, which it already does. It is up to the URL people and others
building "referencing engines" to figure out how to write down the references,
packedage them up, canonicalize them, get at them, etc. Similarly, it is up to
the people defining actual data formats to figure out how to incorporate
references into their data objects. This latter point is exactly the issue that
is now being debated by the newly-formed SGML Working Group, as a matter of
fact -- it turns out that there are several ways to do this sort of thing in
SGML, and the question becomes one of which way is best.

Ultimately, I'm envisioning a complex multimedia object that integrates and
synchronizes all of the various components. Maybe it isn't quite as 
interactive
as a video game, where I might click on a bird and have it fly away, but it
would be nice to have an Acrobat text file with included PostScript pictures
and high quality sound.

Theory says that you could do this in PostScript by extending the syntax
of the file operators approriately. I doubt this will ever happen, however --
most people see PostScript as a final form "leaf" object format these
days.

I know that BBN is working on Location Independent Information Objects for
ARPA, although I don't know what they are doing in this area, if anything. and
I think that one of the ISO groups is also looking at such complex objects.

I guess I'm asking if there is any kind of an overall vision emerging in this
area?

Exactly this sort of "vision" is already emerging from the WWW work, as a 
matter of fact. This work is based on MIME but but not on messaging per se.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>