Interestingly enough, this thread dates back to 1993. I spent some
time trolling the archives to see what I missed during the year from
Feb '93 to Feb '94 when I had no net access. Some of it is _very_
interesting!
In response to MarcA's original proposal for an IMG tag[1], TimBL
wrote[2]:
|I had imagined that figues would be reprented as
|
|<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
|
|where the relation ship values mean
|
| EMBED Embed this here when presenting it
| PRESENT Present this whenever the source document
| is presented
|
|Note that you can have various combinations of these, and if
|the browser doesn't support either one, it doesn't break.
|
|A see that using this as a method for selectable icons means nesting
|anchors. Hmmm. But I hadn't wanted a special tag.
MarcA gave his reasons for going with IMG in [3]. Basically, he wanted
to keep things simple.
But I wish I had a nickle for every time somebody came along later and
said "why isn't the <IMG> tag more general, like an <INCLUDE> tag or
something?" I'd be rich!
I think it's high time we took another look at representing,
displaying, and composing compound documents. The issues are evidently
complex: look at OLE2 and Bento/OpenDoc.
I could plug hytime here as a standard way to express the relationship
between the various parts of a compound document, but I still haven't
done my homework on hytime yet, so I won't.
There's an "open" platform for experimenting with these issues too:
the X11R6 version of ICCCM[4] specifies conventions for embedding one
X client in another (like some ghostview and MidasWWW do with the
embedded gs window).
I'd like to see the CCI idea expanded to a full-blown "message bus"
ala tooltalk. Clearly, on the Mac platform you have to interoperate
with apple-events, and on Windows you have to interoperate with OLE.
There is no established message-passing architecture for X clients,
though the ICE protocol[5] is emerging as a basis for high-bandwidth,
secure, multiplexed interclient communication, and CORBA[6] and DCE
can't be counted out.
I think there will be lots of little protocols on the desktop:
communication between your digicash "wallet" and your browsers;
communication with your "history/hierarchy" tool, your "search"
tool, your videoconferencing tool, etc. I'd like to see all these
protocols described in an interface language, like CORBA's IDL
(though IDL has inherited lots of brokenness from C++).
The cole available from the ILU project[7] will let you:
* specify your protocol in IDL
* convert IDL to ISL, the interface language of the ILU project
* build ILU stubs for various languages, e.g. C, C++, Modula-3,
Common-Lisp, python, etc. (I think Tcl is supported too)
* use various RPC protocols; SunRPC is currently supported, and
the OMG TCP-based interoperability protocol is in the works
* use various transports: SunRPC-style UDP, tcp, and I think
there's support for AppleTalk; I expect ICE could be
used as a transport
I'm not sure how using ILU would help you deploy on Mac/Windows
platforms.
In fact, maybe all this technology is overkill for the problems at
hand. We'll see...
Now I'll take off my propeller-head hat and put on my user hat:
* Why is it so painful to construct a message like this? I had to
painfully copy and paste information from Netscapes "Document
Information" window or some such for each reference below. Why can't
I just do some sort of "paste link" and get the info presto!
(hmmm... reminds me of the original NeXT WWW implementation, with
integrated hypertext editing support. Too bad NeXTStep never really
caught on!)
There are several so-called HTML editors that save you the trouble
of typing <UL>, <LI>, and <P>, but they don't help much when it comes
to linking.
I think a set of user interface conventions for hypertext GUIs will
evolve over the next year or so. Just like cut/copy/paste and the File
menu, we'll see some combination of buttons, menus, and drag-n-drop
idioms evolve into a desktop standard. Maybe by then X will be a
usable desktop platform. Maybe...
Apparently some of the Mac internet tools interoperate in sophisticated
ways like this... Anarchie, Eudora, and MacWeb apparently sling URLs
around invisibly for the user through applevents[9].
* Why is it so painful to send HTML through mail and news?
Why does the www-talk list processor munge MIME headers?
How many readers of this list have MIME-capable mail user agents
configured to handle text/html reasonably well?
Why do we spend so much energy converting mail messages to HTML on the
server side, rather than enhancing clients to understand MIME syntax?
There are quite a few lists where if you send HTML, it will be treated
as text and converted to HTML again (with considerable corruption)!
In a way, it's unfortunate that the linking syntax of HTML isn't
orthogonal to the syntax for paragraphs, bold, italics, and the
like. The MIME external-body mechanism is more appropriately
orthogonal; too bad it's so verbose!
It would make sense, though, if I could represent a hypertext document
as two separate entities: the content, and the links. The content
could be in any format I choose, and the links would be
independent. Several of TimBL's writings on WWW refer to HTML as just
one data format among many that the web architecture could support. The
problem is that HTML is the only data format that can represent links.
The URL syntax gives the address of anchors, but there's no way
to represent the notion:
"There is a link from URL1 to URL2"
in any existing data format except HTML. Sure, we can come up with
ways to express that notion in each data format: PDF, TeX(or dvi),
RTF, etc. But then you have to change a document to put links in it.
I recall there was a paper presented at the Geneva WWW conference
regarding links outside of documents... I'll have to go read it again.
Anyway... back to .mailcap files:
>I don't want the browser to do it itself, I'd like to be able to
>configure my mailcap file on the browser side with something like:
>
> video/mpeg : mpeg_play_embed %s %E
> application/postscript : ghostview_embed %s %E
>
>where %E (E for Embedded_info) could be the id of the window (a
>browser sub-window) where the rendering is to happen.
>
>I'm not sure if an extension of rfc1524 (mailcap syntax) is needed, or
>if a set of conventions would be enough.
How about:
video/mpeg: mpeg_play%s; embed=mpeg_play_embed %s %E
The Mailcap specification[8] allows for keywords like print=, compose=,
etc. Just add another one: embed=
Of course this requires the mpeg player to be a child process of the
browser. It doesn't allow for the case of X server on machine X, web
client on machine W, and video player on machine V, where the web
client wants to invoke the video player. That's where the
tooltalk/CORBA type stuff comes in. Obviously, it's a lot easier to do
in the Mac/Windows world where the distributed computing problems go
away :-)
[1] Date: Thu, 25 Feb 93 21:09:02 -0800
From: [email protected] (Marc Andreessen)
Message-id: <[email protected]>
Subject: proposed new tag: IMG
http://gummo.stanford.edu/html/hypermail/.www-talk-1993q1.messages/174.html
[2] Date: Fri, 26 Feb 93 14:04:55 +0100
From: Tim Berners-Lee <[email protected]>
Message-id: <[email protected]>
http://gummo.stanford.edu/html/hypermail/.www-talk-1993q1.messages/178.html
[3] Date: Fri, 12 Mar 93 22:32:12 -0800
From: [email protected] (Marc Andreessen)
Message-id: <[email protected]>
http://gummo.stanford.edu/html/hypermail/.www-talk-1993q1.messages/249.html
[4] See http://www.x.org, though I can't find the ICCCM itself online.
[5] See http://www.x.org, though I can't find the ICE spec online.
[6] http://www.acl.lanl.gov/sunrise/DistComp/Objects/corba.html
[7] ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html
[8] http://ds.internic.net/rfc/rfc1524.txt
[9] http://galaxy.einet.net/EINet/MacWeb/MacWebFeatures.html