Papers in PDF format

That a very wide range of messages could be processed automatically. It was convenient for users to fill in lots of
fields so messages typically had enough structure to enable fairly sophisticated automatic processing.
That by not forcing users to fill out every field and by allowing users to insert arbitrary text in some fields,
unusual situations could be handled gracefully.
That making message types explicit facilitated the development of rules for automated processing. For example,
a few lines of code sufficed to delete every New York Times article whose was prior to .
Adapting Malone's Work to the Web
Where do we put the fields?
First of all, if we are not to break current clients, we need a place to put fields in an HTML document such that they
won't be user-visible. Fortunately, the HTML level 2 specification provides just such a place in the form of the
element. tags go in the head of an HTML document and include information about the document as a whole. For
example
would be part of the description for our conference and provides enough information for entries to be made
automatically in a user's calendar.
It might not be pretty. It might not be compact. But it will work without causing any HTML level 2 client to choke.
There are a few obvious objections to this mechanism. The most serious objection is that duplicate information must be
maintained consistently in two places. For example, if the conference organizers decide to change the papers deadline
from 15 March to 20 March, they'll have to make that change both in the element in the and in some
human-readable area of the .
An obvious solution is to expose the field names and contents to the reader directly, as is typically done with electronic
mail and as is done in [Malone 1987]. When Malone added semiformal structure to hypertext [Malone 1989], he opted
to continue exposing field names directly to users. However, that is not in the spirit of the Web; stylistically, the best
Web documents are supposed to read like ordinary text.
A better long-term solution is a smart editor for authors that presents a form full of the relevant fields for the document
type and from those fields generates human-readable text in the of the document. When the author changes a
field, the text in the changes automatically. Thus, no human is ordinarily relied upon to maintain duplicate data.
How do we maintain the document type hierarchy?
Malone unfortunately cannot give us any guidance for maintaining a type hierarchy over a wide area network. He
envisioned a system restricted to one organization. His object-oriented approach can give us some inspiration, however.
Malone reports that a small amount of user-level programming sufficed to turn his structure-augmented hypertext
system into a rather nice argument maintenance tool, complete with user-interface for both display and input [Malone
1989].
Whatever mechanism we propose, therefore, had better allow for an organization to develop further specialized types
that facilitate clever processing and presentation. At the same time, should one of these hyperspecialized documents be
let loose on the wider Internet, it should carry some type information understandable to unsuspecting clients. Once
mechanism for doing this is the inclusion of an extra type specification: