I would like to see a graphics composition language which allows a structured
display to be composed on the screen from a number of items, which may be
local or remote. For example, I would like to see a chess screen made up
of a composition of a basic board, and a bunch or pieces, all identified
by their network or local addresses (URIs). These would be cached in
practice, so to redraw the board would be the very rapid operation of
respecifying the structure. Another example is a picture of a conference
room composed of a background, an overhead projector screen which is in
fact a whiteboard, or IRC, session, and people sitting around the table
which are GIFs, or videos for those with cameras. We have the formats
for the basic graphics (though only TIFF a la NeXT has the much-needed
transparency channel I believe). We need a composition language.
There will be those who suggest adapting PDF, which is basically
postscript with the ability to embedd other formats.
Maybe the renderman format would have something to give us.
There will be those who suggest augmenting TIFF, using its general
tagging.
There will be those who say it should be SGML.
There will be those who say that HyTime ought to be used for this,
as that was what it was indended for more or less.
There will be those who feel like writing it in an afternoon from
scratch.
(By the way, I disagree that postscript is too terribly
_big_ -- with display postscript coming with X, and already doing a
neat job as the screen interface in this system as I write, if
it was what we wanted I would go for it. I feel though that
we want something very declarative, rather than procedural,
as a base. I would like it to support lazy eveluation, so
that when a bit of embedded video becomes covered by another
window, the bandwidth can be saved, or if I can't see the
output of a simulation, the CPU can be saved. "If you never
have a dream, then you never have a dream come true".)
Clearly some 3d or fake 3d ability is useful. Taking the
object-oriented approach, I would imagine objects suitable
for composition responing to, according to their sophistication,
methods
Renderself();
RenderSelf(viewed_from_x,y,z);
Renderself(viewed_frorm_x,y,z, lighting_conditions);
The results would, with HTTP, be returned in any format the
client could handle, so those who could handle video might get
back a video stream, those which can handle 3d might get back 3d,
defaulting down to 2d with transparency or just plain GIFs.
(I guess we rule out 3d video, but video with transparancy
would be cool -- using color separation overlay to paste
people from their own blue painted conference room into
a common virtual environment).
An object which only had a 2d representation would always
return the same picture, with the result that, for example,
when one rotated the conferenec room, the people would
always be facing one. That is a reasonable compromise,
the sort of thing which makes practical systems really work,
and turn smoothly into ultimate systems with time, bandwidth
and money.
I would like dynamic editing, so that the
chairperson (chairobject? ;-) can mouse drag Prof. Sleator to the
head of the table
to explian his ideas, and he can drop documents into the
overhead projector, or one can drag/drop the chess pieces)
We would have a great basis for consutruction of networked
VR, graphical MUDDS, and cyberspace would never be the same again.
This would be totally in keeping with web tradition in
being a powerful means of communication with an incredibly
intuitive interface, and with the ability to grow in
sophistication limited only be the imagination, and all based
on not very much.
In fact, many of the requirements, such as the format negotiation
and the embedding of graphics by reference go, much of it is there
in differing amounts in different clients, and spec'd out.
The missing thing is the composition language, with its 3d elements.
Which is why Prof. Sleator's message hits the nail on the
head.
I would encourage a discussion of this, an evaluation of what
is there some rapid work toward some prototypes. I would
strongly encourage a viuew of this as just another sort of
object, with various possible representations (just like
basic images -- in fact this is an image object, embeddable
in a document). Let's go fo it...
Tim Berners-Lee
_______________________________________________________
Begin forwarded message:
>
>From: Daniel Sleator <sleator@cs.cmu.edu>
>Date: Wed, 26 Jan 94 22:58:16 EST
>
>I wrote most of the internet chess server (which can currently be
>reached with "telnet ics.uoknor.edu 5000"). A number of other
>programmers have written interfaces that run on your local
>PC/MacIntosh/Xterminal/Next. The interface parses the output from the
>chess server and displays a pretty chess board on your screen. It
>also allows the user to make moves with the mouse. These mouse
>strokes are converted into algebraic chess move notation. Some of the
>interfaces show a dynamically changing clock, indicating the amount of
>time remaining for each player.
>
>Each of these interfaces is a custom-made special purpose-program for
>connecting to this chess server. A similar set of interfaces has been
>created for use with the go server.
>
>This whole set-up is really cumbersome for a number of reasons.
>(1) It's very difficult to set up other game servers with graphics,
>because a whole set of special purpose interface programs must be
>written, one for each major platform. (2) Any change in the chess
>server must be backward compatible with all the interfaces out there.
>This limits the the way the server can develop. (3) When a separate
>new platform emerges, a new interface must be written for each of the
>internet games with graphics.
>
>All of these problems could be solved by a standard language for
>expressing the simple types of graphics needed for these games,
>combined with a set of interfaces to interpret this language on a
>variety of platforms. Postscript suffers from at least two drawbacks.
>(1) It's extremely verbose -- since many users connect through slow
>lines, this a problem. (2) full postscript is a HUGE language that is
>very difficult to implement, and 99% of it is unnecessary for these
>purposes.
>
>I believe that the development of such a set of tools would spur a
>tremendous explosion of new simple graphics games and applications
>that could run through telnet the way the chess server does now. It
>would be possible for one person to write a new game (such as double
>bughouse chess) without having to write a half dozen graphics
>interfaces. Many really cool things change from being impossible to
>being quite feasible. (The PLATO system developed in the 70s at the
>University of Illinois had some of these properties: simple graphics
>available to all users, fast interaction among a large pool of users.
>The result was the development of a number of very popular and
>engrossing interactive games.)
>
>So, my question is: does a language with these properties already
>exist? If not, how do we go about creating it? This whole idea seems
>to fit quit well into the philosophy of Mosaic, which is a standard
>interface to the net that runs on all platforms. If it emerges, would
>this new type of network interaction be built into Mosaic?
>
>Please forward this message to anybody else who you think would have
>some useful insight on this problem. Thanks.
>
> Daniel Sleator
> Professor of Computer Science
> Carnegie Mellon University
>
>