:You could some kind of kludge that might solve a small set of problems
:but it would hurt the WWW project in the long run.  There are already
:too many kludges making their way in.  What is needed is a much cleaner,
:better thought out version of HTML/HTML+.  Hytime isn't the answer either.

My original idea was to do this at the client side, for the same reasons
others have expressed.  However, I agree that HTML and especially Mosaic is
beginning to become quite a kludge.  Features (such as ISMAP) have been patched
in here and there, with upward compatibility being the primary issue (so old
clients and servers can ignore the new features). There are a lot of features
I would like to see in HTML/Mosaic:
        1. Full Gopher+ Support (Attributes, Views, ASK Blocks)
        2. Full WAIS Support (Cover sheets, relevance feedback)
        3. Transclusion
        4. Inline Vector Graphics
        5. Inline MPEG
        6. Tabs-Columns outside of <PRE>
        7. Text Wrapping around graphics
        8. Inline Editing/Customization (extended annotation/hotlist to let
                browsers build their own personal pages)
These features and others would make the WWW THE World-wide publishing tool,
with almost anything any publisher would want to produce great documents.
However, they would also make the clients like Mosaic the most unwieldy things
in the world!  Who in their right mind would expect Marc, Eric, and the rest
to program this Wunderkind on a university budget?

I have two possible solutions:
1. Use modular clients with inter-process communication (i.e. tooltalk, OLE).
There would be small, but full-featured, clients for gopher+, wais, graphics
display, animation, etc, with WWW (i.e. mosaic) being the background.  The sub-
clients would appear in simple windows inlined in the text (perhaps with a
floating menu that would appear when the mouse moved over the window).
Transclusion would be no more difficult, since it would include another www
client.
+-----------------------+
+-----------------------+
|WWW lksdlkfjsdlkjslkjl |
| slkjflksdjlksjflksjdl |
| sfslkdjfsd +--------+ |
| skdfkljdlk |gif-app | |
| slkdjflksj |boy.gif | |
| sfdsjhjhsd +--------+ |
| sjdsjkhdkjkjhsdkjhjsj |
| +----------+          |
| |gopher-app|          |
| |1.lkjhh   |          |
| |2.sldjkd  |          |
| |3.sdhdj   |          |
| +----------+          |
+-----------------------+
Very long-range idea, of course.

2. Perhaps HTTP is just not the right framework for things this complex.  Any
of you that use WordPerfect very much (my favorite word processor), realize
that it is becoming far too complex for its code-tagged text format.  Have you
seen Acrobat or Folio Views?  They do a much better job of true electronic
publishing.  Maybe the answer is to take a more robust publishing format and
make it more net-aware.  

3. Has anybody seen any really good SGML DTD's for complex publishing?  Since
HTML is itself an SGML DTD, it could easily borrow the needed capabilities.

Well, that's my 3 cents.  It's all very complex, which doesn't bode well for
keeping all these services in the public domain...

____  ________
.   \/    .   \      Brandon Plewe              +--+
____/\___ ____/      Dept. of Geography         |  +-+
.   \    \           SUNY at Buffalo            |SG  |
____/____/.          pl...@geog.buffalo.edu     |*___|
 my real .sig is <A HREF="http://zia.geog.buffalo.edu/plewe/home.html">here</A>