Re: Embedding of Mime parts

Gina Faber (gfaber@Teknowledge.COM)
Sat, 21 Jan 1995 08:54:14 +0100


(Geez, when it rains, it pours! Why does the conversation in this group
always happen in spurts? Or is that a listserver artifact?)

Anyway, my comments pertaining to HTML-editing and creation of links
appear below.

From: "Daniel W. Connolly" <>

In message <>, Daniel Dardailler writes:
>Hello, I'm new to this group, and I'd like to know if work has already
>been done or is going on on this subject.

-- discussion of IMG origins, and embedding considerations deleted --

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

I know of two Unix-based HTML editor development efforts which are trying to
address the intelligent "slinging" of URL's for the purposes of link creation
in HTML. A third is not HTML, but uses a different hypertext representation.

The first is Phoenix, a tcl/tk-based HTML editor, which allows the transfer of
a URL in one screen to a input box in an adjacent screen with a single
click (for example, click on an item in your hotlist, it appears as the
object of a new link in the other window.


The second is the Webber tools, being developed under an ARPA grant as
an application in the JTF-ATD architecture. Links are created between two
html documents in two editor application windows by two button clicks: 1 on
the source page, and the other on the target page. Normal highlighting is
used to specify mid-HTML target anchor references. A subsequent "Save" makes
the appropriate changes to the two HTML files involved. A Tcl-DP Blackboard
(soon to be upgraded to IDL/C++) is used to facilitate the window-to-window
communication for the transfer of URL's so that the user never sees it.

The Webber tools, which are part of a larger all-<well-specified>types-allowed
WebServer concept, are scheduled to debut in the JTF-ATD development community
sometime this year; they are not available publicly at this time.
The best reference available is a description of the project:

LinksWare, a Mac app which we looked into about 9 months ago, allows the user
to define links simply by gesturing--pointing with the mouse, and clicking in
the window displaying the target. This action creates the link (and reference
anchor) instantaneously because the representation of the links of each object
is separated from the content itself. If I remember correctly, word
recognition was used to match the links to their place in the page. The nifty
thing was that this SW could include a variety of formats of content
because it wouldn't need to know how to edit the content to put the links

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

So will I! We've considered and begun including the notion of external
link representation in the WebMan work, but have back-burnered it for now.

Gina Faber

Gina Faber					Teknowledge Corporation				(415) 424-0500
--								     --
                "To live only for some future goal is shallow.
       It is the sides of the mountain which sustain life, not the top."
               -- "Zen and the Art of Motorcycle Maintainance"