[7274] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: Embedding of Mime parts

daemon@ATHENA.MIT.EDU (Gina Faber)
Sat Jan 21 04:00:00 1995

Date: Sat, 21 Jan 1995 09:22:18 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: gfaber@Teknowledge.COM
From: gfaber@Teknowledge.COM (Gina Faber)
To: Multiple recipients of list <www-talk@www0.cern.ch>

Dan,

(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" <connolly@hal.com>

   In message <9501131604.AA04178@soleil.x.org>, 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.

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

http://http.bsd.uchicago.edu/~l-newberg/phoenix.html
   
Webber 

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:
http://www.teknowledge.com/JTF/webman-overview.html 

LinksWare
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
in.

http://www11.w3.org/hypertext/Products/Overview.html#20



   * 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
gfaber@teknowledge.com				(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"





home help back first fref pref prev next nref lref last post