Papers in PDF format

left to do? Style sheets don't let one publish mathematics, figures with captions, or dozens of other things faciliated by
old languages like LaTeX or newer systems like Microsoft Word.
We could just add hyperlinks to LaTeX. This is more or less what a group of people at Los Alamos National Labs did a
few years ago. I don't think there are really sound intellectual arguments against this approach, but sentiment seems to
be on the side of keeping HTML. If we are indeed stuck with HTML, though, perhaps there is a better way to extend it.
Our methodology for extending HTML seems to be the following
1. sit down with a few formatting languages in common use
2. argue about which are the most commonly needed commands
3. argue about whether Web browser programmers are really up to the task of writing the code that implements
those commands
At this rate, it will be the year 2000 before HTML is really powerful enough for most people, by which time it may have
been replaced with Adobe's Portable Document Format (PDF).
I'd like to suggest an alternative approach:
1. choose a set of 100 documents that represent the spectrum of things we'd like to see on the Web
2. come up with a language capable of expressing the author's intent in 98 of those documents
3. come up with a language capable of expressing the designer's intent in 98 of those documents
4. add to HTML the semantics of the languages developed in the preceding two steps
Fixing the Structure Problem
Can the same approach solve the structure problem? What if we locked a bunch of librarians and a handful of
programmers in a room together and made them think up every possible semantic slot that any Web document could
ever want to fill. They'd come out with a list of thousands of fields, each one appropriate to at least a small class of
documents.
An obvious reason why this wouldn't work is that the committee could never think of all the useful fields. Five years
from now, people are going to want to do new, different, and unenvisioned things with the Web and Web clients. Thus,
a decentralized revision and extension mechanism is essential for a structure system to be useful.
A deeper reason why this wouldn't work is that nobody would be able to write parsers and user interfaces for it. If a user
is developing a Web document, does he want to see a flat list of 10,000 fields and go through each one to decide which
is relevant? If you are programming a parser to do something interesting with Web documents, do you want to deal with
arbitrary combinations of 10,000 fields?
Malone's Work on Semistructured Messages
Back in the early 1980s, Tom Malone and his collaborators at MIT developed the Information Lens, a system for
sharing information within an organization. He demonstrated how classifying messages into a kind-of hierarchy
facilitated the development of user interfaces. Figure 1 shows one of Malone's example hierarchies [**** insert Figure 6
from Malone's paper]. For each message type, there is an associated list of fields, some of which are inherited from
superclasses. Consider the class . Fields such as and are
inherited from the base class . Fields such as are associated with the class
itself.
Each message type also has an associated list of suggested types for a reply message. For example, the suggested reply
type for is . Most importantly, the decomposition of
message types into a kind-of hierarchy allows the automatic generation of helpful user interfaces. For example, once the
system knows that the user is writing a , that determines which fields are offered for
filling and what defaults are presented. Fields having to do with software bugs or New York Times articles are not
presented and fields such as and may be helpfully defaulted with the usual room and time.
What did Malone's team learn from this?