Shown here are the raw source texts and contents (with titles simulated) of the oldest surviving HTML files. All such files from the November 13, 1990 through January 10, 1991 period are contained within this file, both as their displayed form and as their raw text. The numerous mistakes and variations and non-standard usages show this version of HTML to have been simply hand-entered.
This period is markedly different from that which follows it (and which spans from
January 23, 1991 through November 23, 1992), not only in what it is missing (quite a
number of tags introduced in the next version of HTML and the first to use the NeXT HTML
editing tool), but also in some things it possesses that the next version does not, namely
the <ol> element, and closing </p> tags. Another
thing only seen in this period (but there is some indication that this lingered into the
next period, but was completely phased out by the end of that period) was the use, carried
over from a "SCRIPT" Language, of a blank line to create a paragraph delimiter.
This may even have predated the <p> tag, or else existed concurrently
from the beginning alongside it. In this document, these double carriage returns are
consistently rendered as paragraph breaks. A number of such paragraph breaks can be seen
within these files. Also never seen here are the name and href
attributes of <a> together in any of all the 64 occurrences of that
element seen in the files shown below, enough to establish a significant statistical
likelihood that the two attributes were not permitted together, despite the fact that they
have been permitted together in all future versions of HTML. Another thing not seen here
is the "&" character, either as a stand alone character (for
display as is) or as the lead byte of a character entity reference. Most likely it was
just not needed during this period, since there are several sightings of it in the next
phase of HTML in which the "&" character simply stands as a raw
character, evidently meant to display as is.
The DTD I have constructed for validating these files, namely "html0.a.dtd," is
used for checking most of these files. Click on the "(Validate)" link at the end
of each to see how they fared as files, as best as one can discern regarding the
"standards" of this earliest period. For this validation, I have prepared local
copies of each file to which I have added the <!DOCTYPE> declaration to each to
link it to that DTD. In addition, many of these files contain / and #
and @ characters that force me to add quotation marks around the link pointer
fields, so as to prevent the rise of spurious errors. No other changes have been done to
these files, so any other errors found (apart from the two standard warnings about not
knowing whether to parse by XML or SGML and about document level character encoding) indeed
point to actual errors in the files themselves. Some files, having the </p>
tag, actually use the
<!DOCTYPE HTML SYSTEM "http://www.the-pope.com/html0.a.dtd" [ <!ENTITY % HTML.zero.b "INCLUDE"> ]>
form of the <!DOCTYPE> declaration to allow for this closing tag,
actually only used briefly towards the end of this period. The last three files included
here, modified during the next phase of HTML, on one case certainly added a new element from
that phase, though for here they are still validated using my "html0.a.dtd," DTD.
These files seem to represent the sum total of what is known of this earliest period of HTML development. No other surviving HTML files have been identified as being from this period, apart from some that have been modified at a later time, and seem to have been modified to conform to a later version of HTML. It was not until mid-1991, with the next version of HTML having replaced this version, that an attempt to document the tags and attributes of HTML began to be drafted and made available online.
Hypertext Links - Windows Internet Explorer
A link is the connection between one piece of hypertext and another.
<title>Hypertext Links</title> <h1>Links and Anchors</h1> A link is the connection between one piece of <a href=WhatIs.html>hypertext</a> and another.
This is the very oldest (least recently modified) HTML file known to exist on the
entire internet. Notice how ancient <title>, <h1>,
and <a> are. Of course <a> would be this old since
it was the reason for which the other small list of elements were created so as to provide
a context for. Is the <p> element this ancient?
There was not a lot of discussion of this at ECHT90, but there seem to be two leads:
<h1>Standardisation</h1> There was not a lot of discussion of this at <a href=Introduction.html>ECHT90</a>, but there seem to be two leads: <ol> <li><a href=People.html#newcombe>Steve newcombe's</a> and Goldfarber's "Hytime" committee looking into SGML, and <li>An ISO working group known as MHEG, "Multimedia/HyperText Expert Group". led by one Francis Kretz (Thompsa SA? Rennes?). </lo>
Notice the incorrect "</lo>" tag at the end. But despite this
it does show that the <ol> element existed by this point. Notice also
the absence of a <title> or any equivalent. Perhaps that was considered
optional at this point.
Where to Store The Links - Windows Internet Explorer
There were mixed feelings at ECHT90 about whether link information should be stored centrally in a database (or in several), or in the documents themselves.
The advantage of keeping the link information with the document itself is that when the document is modified, and anchors are moved, the information only has to be changed in one place.
One advatage of storing them in a separate database is that you can quickly generate large-scale views of the web.
Another advantage stated was that one could generate a link to something without having write access to it. Now this is an important point, but unfortunately not a valid conclusion if one makes a link to an anchor within a document, because an anchor within a document must be generated. Even if one (sensibly) separates the concepts of link information (mapping one anchor id to another) and anchor information (mapping anchor id to position in a document), there is always the creation of an anchor involved in making a link. If links are bidirectional, then link creation wil in general involve changing data in two different domains of protection.
If the anchor information is within a database, then when the document is edited, the database must be refreshed. This implies that only special link-aware editors may be used. This may not be a problem in the long term for Apple is they decide that ALL applications will be link-aware, but it rather constraining and rules out the use of existing applications. Intermedia uses this approach, perhaps prompting Norman Meyrowitz's remark in his ECHT90 tutorial that "Keeping track of anchors within documents turns out to be one of the most interesting topics in hypermedia research"
This alternative is not acceptable to the WWW project for editable data as we cannot rewrite all applications and the operating system (nor do we want to). However, servers which generate data from other sources, and servers which disseminate essentially uneditable data, may use this technique.
The WWW architecture is basically independant of the choice of where the link information is stored as different servers may use different techniques. Indeed, WWW will allow evaluation of the various possibilities witin the same system.
An intersting compromise we could look at in WWW is keeing the masters inside the document, but using a daemon to generate a database. There is no reason why one should not mix the alternatives: dome nodes could contain the entire link information, others just a UID to be looked up in a database.
<title>Where to Store The Links</title> <h1>Where should one store links?</h1> There were mixed feelings at <a href=../Conferences/ECHT90/Introduction.html>ECHT90</a> about whether link information should be stored centrally in a database (or in several), or in the documents themselves. The advantage of keeping the link information with the document itself is that when the document is modified, and anchors are moved, the information only has to be changed in one place. One advatage of storing them in a separate database is that you can quickly generate large-scale views of the web. Another advantage stated was that one could generate a link to something without having write access to it. Now this is an important point, but unfortunately not a valid conclusion if one makes a link to an anchor within a document, because an anchor within a document must be generated. Even if one (sensibly) separates the concepts of link information (mapping one anchor id to another) and anchor information (mapping anchor id to position in a document), there is always the creation of an anchor involved in making a link. If links are bidirectional, then link creation wil in general involve changing data in two different domains of protection. <h2>Using a database</h2> If the anchor information is within a database, then when the document is edited, the database must be refreshed. This implies that only special link-aware editors may be used. This may not be a problem in the long term for Apple is they decide that ALL applications will be link-aware, but it rather constraining and rules out the use of existing applications. Intermedia uses this approach, perhaps prompting Norman Meyrowitz's remark in <a href=../Confernces/ECHT90/Tutorial6.html>his ECHT90 tutorial</a> that "Keeping track of anchors within documents turns out to be one of the most interesting topics in hypermedia research" This alternative is not acceptable to the WWW project for editable data as we cannot rewrite all applications and the operating system (nor do we want to). However, servers which generate data from other sources, and servers which disseminate essentially uneditable data, may use this technique. The WWW architecture is basically independant of the choice of where the link information is stored as different servers may use different techniques. Indeed, WWW will allow evaluation of the various possibilities witin the same system. An intersting compromise we could look at in WWW is keeing the masters inside the document, but using a daemon to generate a database. There is no reason why one should not mix the alternatives: dome nodes could contain the entire link information, others just a UID to be looked up in a database.
This exemplary file shows the earliest surviving <h2> element. The
use of this (along with <h1> seen in previous files) implies an intent
to implement the full SGML suite of Header elements <h1> through
<h6>. The double carriage return lines seen here are instances of where
the double carriage return was meant to serve as a paragraph break. At least some of the
earliest user agents in use at this time would have so displayed double carriage returns.
Glasgow Online - Windows Internet Explorer
This was a very carefully handcrafted 16MB hypertext built by Patricia Baird and around 30 others at Strathclyde. It is a complete town guide to Glasgow, including maps, and using lots of graphics. Uses Hypercard 1. Distributed for 25 pounds to cover the 10 or so disketes if you want one.
<title>Glasgow Online</title> <h1>Glasgow Online</h1> This was a very carefully handcrafted 16MB hypertext built by <a href=People.html#baird>Patricia Baird</a> and around 30 others at Strathclyde. It is a complete town guide to Glasgow, including maps, and using lots of graphics. Uses Hypercard 1. Distributed for 25 pounds to cover the 10 or so disketes if you want one.
<h1>Journals in Hypermedia</h1> <ol> <li>"HyperMedia", edited by <a href=People.html#baird>Patricia Baird</a>. I have a sample copy. <li>"Electronic Publishing - Origination, Dissemination and Design", edited by <a href=People.html#Futura>Richard Futura</a>. I have a sample copy. <li>The ACM "SIGLINK" special interest group Bulletin. This SIG has just been formed. I have subscription information (ACM members $20, Bulletin only $16. Non-members $56) </ol>
This is the oldest correct <ol> element. Note again that
<title> is missing.
The Perseus project - ECHT90 - Windows Internet Explorer
This is a very complete hypertext on classical Greek civilisation, which incorporates philological, archaeological and historical views of the topic. It was presented in the penultimate paper session of ECHT90 by its editor in chief, Elli Mylonas.
Examples of date held on the Perseus CDROM are original Greek texts with a parallel scrolling English translation, maps of ancient sites, and photographs of archeological remains.
The Perseus data is stored in SGML, and as postscript and colour slides, and converted for distribution into Hypercard form, with some loss of information. Links are generated in a similar manner to the Microcosm generic keyword system. The disks are being shipped to various sites for trial use by students. Students are encouraged to take notes by marking particluar nodes they have found as being of interest to them.
<Title>The Perseus project - ECHT90</title> <h1>Perseus Project</h1> This is a very complete hypertext on classical Greek civilisation, which incorporates philological, archaeological and historical views of the topic. It was presented in the penultimate <a href=Programme.html#pap9> paper session of ECHT90 by its editor in chief, <a href=People.html#Mylonas>Elli Mylonas</a>. <p> Examples of date held on the Perseus CDROM are original Greek texts with a parallel scrolling English translation, maps of ancient sites, and photographs of archeological remains. <p> The Perseus data is stored in SGML, and as postscript and colour slides, and converted for distribution into Hypercard form, with some loss of information. Links are generated in a similar manner to the <a href=../../Products/Microcosm.html>Microcosm</a> generic keyword system. The disks are being shipped to various sites for trial use by students. Students are encouraged to take notes by marking particluar nodes they have found as being of interest to them.
This file has the error that the first link is not closed with a </a>
tag, again evidence of hand entering. This file also contains the oldest surviving example
of the <p> tag, here being used apparently as a separator tag since it
only occurs in between paragraphs and not always before them, and there is no closing tag.
Strutcured Documents vs. HyperText - Windows Internet Explorer
A debate which surfaced many times at ECHT90 was that as to whether a document should have an overall structure, as in an SGML document, or whether it should be free to be a tangled web.
The proponents of an enforced structure pointed out that
There were obviously a number of different attitudes to authorship at the conference. Many sytems were created with great care by profesional authors for dissemination to a non-expert public. In these cases, such as Glasgow Online and the Perseus project, the authors had taken the trouble to predict likely paths neeed by users, and to insert them. A document tree structure generally existed, but was not always obvious.
The WorldWideWeb project aims to, by contrast, allow information to be gathered from authors who may be no more expert than their readers. In this case, the author will not have the time (or sometimes imagination) to guess the reader's viewpoint. In this case, it must be easy for the reader to be able to view the system in his own way without the author's view being imposed on him.
A third category of author is one who assumes he knows better than the reader, and whose intent is communicate completely his ideas, including the structure of them. The reader is assumed to be a novice, and have no association of ideas in the area himself. This is a the approach of conventional textbooks, and sometimes has some advantages. The experienced reader who does well understand the field can also benefit from this approach in that he may be interested to see the point of view implied by the author's structuring. However, to read a book in this way takes some time and a clear mind. It is this third case in which the structure of the document is important.
<Title>Strutcured Documents vs. HyperText</title> A debate which surfaced many times at <a href=#Introduction>ECHT90</a> was that as to whether a document should have an overall structure, as in an SGML document, or whether it should be free to be a tangled web. <p> The proponents of an enforced structure pointed out that <ol><li>It conveyed better the author's intent <li>It provided a more steady basis for the reader's assimilation of the material <li>It prevented people from getting lost </ol> <h2>Author attitudes</h2> There were obviously a number of different attitudes to authorship at the conference. Many sytems were created with great care by profesional authors for dissemination to a non-expert public. In these cases, such as <a href=GlasgowOnline.html>Glasgow Online</a> and the <a href=Perseus.html>Perseus</a> project, the authors had taken the trouble to predict likely paths neeed by users, and to insert them. A document tree structure generally existed, but was not always obvious. The WorldWideWeb project aims to, by contrast, allow information to be gathered from authors who may be no more expert than their readers. In this case, the author will not have the time (or sometimes imagination) to guess the reader's viewpoint. In this case, it must be easy for the reader to be able to view the system in his own way without the author's view being imposed on him. A third category of author is one who assumes he knows better than the reader, and whose intent is communicate completely his ideas, including the structure of them. The reader is assumed to be a novice, and have no association of ideas in the area himself. This is a the approach of conventional textbooks, and sometimes has some advantages. The experienced reader who does well understand the field can also benefit from this approach in that he may be interested to see the point of view implied by the author's structuring. However, to read a book in this way takes some time and a clear mind. It is this third case in which the structure of the document is important.
In this file, the link to the ECHT90 Conference is (unlike in the other files that
point to it) merely an internal reference. Is this a mistake or were many of these
files formerly combined into a single large file, within which such a local reference
could have made sense? This is not the only such file from this era to make me
consider this a significant possibility. Perhaps at one point there had been fewer
but larger files which were then later broken up into many smaller files. Also, the
opening <title> tag starts with a capital "T,"
again evidencing hand-entry. Note also again, the double carriage returns were used
for paragraph breaks in some cases, along with the <p> tag in other
cases.
Technical points of note from ECHT90 - Windows Internet Explorer
A few interesting technical issues raised or discussed at ECHT90 are as follows:-
<title>Technical points of note from ECHT90</title> <h1>Technical Issues raised</h1> A few interesting technical issues raised or discussed at <a href=Introduction.html>ECHT90</a> are as follows:- <ol> <li><a href=../../WWW/StoringLinks.html>Where to store the link information - in a database or in a document.</a> <li><a href=Standardisation.html>The state of standardisation</a> <li><a href=Structured.html>Whether a strict document structure (tree-like, as in SGML) was a good idea for hypertext documents</a> <li><a href=HTandIR.html>The relationship between Information Rerieval technology and Hypertext</a>. </ol>
Hypertext HTML formatting example
This file contains a test set of HTML mark-up, as a test of hypertext browsers and an example of the syntax of the tags. See also:
Here is an anchor which leads to the VM FIND command. Note the nested highlighting (hp2) within the anchor. If you want to click on this, you will go to the system default page.
Now THIS leads to anchor #2 in this file, and if you want to click on THIS, you should go to the system default page with anchor #2 selected. Now the word "destination" is a named destination anchor, connected to the word "source". Clicking on the destination shouldn't do anything. Selecting the source should lead to the destination.
Now let's go through the limited set of markup tags which we accept. The title, "Hypertext HTML formatting example" was between TITLE tags. "Test Dataset" at the top of this page was a Level One Heading (H1). The quick brown fox jumps over the lazy dog. In Hertford, Hereford and hampshire, hurricanes hardly happen.
Here is some text which follows the heading. The quick brown fox jumps over the lazy dog. In Hertford, Hereford and hampshire, hurricanes hardly happen.
Here is some text which follows the heading. The quick brown fox jumps over the lazy dog. In Hertford, Hereford and hampshire, hurricanes hardly happen.
This is a test paragraph. It is separated from the previous one by a P paragraph mark.
This new paragraph was separated from the previous one by a blank line, a horrible leftover from SCRIPT, which violates the free format of the text.
This was delimited in the same way in the source. The blank line should have the same effect as a paragraph mark.
We have included in HTML some tags from the SGML tagset used at and once supported at CERN by quite a lot of documentation and SGML examples. The HTML parser will ignore tags which it does not understand, and will ignore attributes which it does not understand of CERN-SGML tags. Of course, the HTML parser will not accept any commands in the SCRIPT language.
Now for an example section, in monospaced font:
_-_
[o,o]
\-/
This text is laid out using fixed-width characters
-----------
It uses the <XMP> tag, and can contain embedded < and > signs. It has
tabs every eight columns like good old simple systems we know and love.
12345678123456781234567812345678123456781234567812345678123456781234567812345678
! ! ! ! ! ! ! ! ! !
Column: First Second Third Fourth Fifth Sixth Seventh Eighth Ninth
Index: 1 2 3 4 5 6 7 8 9
Junk: The Quick brown fox jumps over the lazy dog.
After the example text, we revert to the default again.
Now lets us try out a glossary.
And after that dazzling display of formatting, how about an ordered list: (We support it as an unordered list)
And now, how about an unordered list:
Now let's try a "LISTING" section.
123456781234567812345678123456781234567812345678123456781234567812345678123456781234567 ! ! ! ! ! ! ! ! ! ! ! Column: First Second Third Fourth Fifth Sixth Seventh Eighth Ninth Tenth Index: 1 2 3 4 5 6 7 8 9 10 Junk: The Quick borwn fox jumps over the lazy dog again!
This is the end of the test file.
<TITLE>Hypertext HTML formatting example</TITLE>
<h1>Test Dataset</h1>
<h2>Introduction</h2>
This file contains a test set of HTML mark-up, as a test of hypertext browsers and
an example of the syntax of the tags. See also:
<ol>
<li><a href=news:1990Oct17.231522.17662@midway.uchicago.edu>An arbitrary news
article</a>
<li><a href=news:alt.hypertext>The newsgroup on hypertext</a>
<li><a href=file:/tbl/hypertext/TheProject.html>More details about the WWW project.</a>
</ol>
<h2>Some anchors</h2>
<h3>Leading to whole nodes</h3>
Here is an anchor which leads to <a Href=http://crnvmc/FIND/PUB.P.HELPCMS.FIND(X,G)>the VM <hp2>FIND</hp2> command.</a> Note the nested highlighting (hp2) within the
anchor.
If you want to click on <a href=file:/usr/local/lib/WWW/default.html>this,</a>
you will go to the system default page.
<h3>Leading to anchors within nodes</h3>
Now <a href=#2>THIS</a> leads to anchor #2 in this file,
and if you want to click on <a href=file:/usr/local/lib/WWW/default.html#2>THIS,</a>
you should go to the system default page with anchor #2 selected.
Now the word <a name=dest1>"destination"</a> is a named destination anchor,
connected to the word <a href=#dest1>"source"</a>. Clicking on the destination
shouldn't do anything. Selecting the source should lead to the destination.
Now let's go through the limited set of markup tags which we accept.
The title, "Hypertext HTML formatting example" was between TITLE tags.
"Test Dataset" at the top of this page was a Level One Heading (H1).
The quick brown fox jumps over the lazy dog. In Hertford, Hereford and hampshire, hurricanes hardly happen.
<h2>Level two heading</h2>
Here is some text which follows the heading. The quick brown fox jumps over the lazy dog. In Hertford, Hereford and hampshire, hurricanes hardly happen.
<h3>Level 3 heading</h3>
Here is some text which follows the heading. The quick brown fox jumps over the lazy dog. In Hertford, Hereford and hampshire, hurricanes hardly happen.
<P>
This is a test paragraph. It is separated from the previous one by a P paragraph mark.
This new paragraph was separated from the previous one by a blank line, a horrible
leftover from SCRIPT, which violates the free format of the text.
This was delimited in the same way in the source. The blank line should have the
same effect as a paragraph mark.
We have included in HTML <hp2>some</hp2> tags from the SGML tagset used at and once supported at CERN by
<a href=http://crnvmc/FIND?sgml>
quite a lot of documentation and SGML examples.</a>
The HTML parser will ignore tags which it does not understand, and will ignore
attributes which it does not understand of CERN-SGML tags.
Of course, the HTML parser will not accept any commands in the
<a href=http://crnvmc/FIND/pub.p.helpcms.xscript>SCRIPT</a> language.
<p>Now for an example section, in monospaced font:
<xmp>
_-_
[o,o]
\-/
This text is laid out using fixed-width characters
-----------
It uses the <XMP> tag, and can contain embedded < and > signs. It has
tabs every eight columns like good old simple systems we know and love.
12345678123456781234567812345678123456781234567812345678123456781234567812345678
! ! ! ! ! ! ! ! ! !
Column: First Second Third Fourth Fifth Sixth Seventh Eighth Ninth
Index: 1 2 3 4 5 6 7 8 9
Junk: The Quick brown fox jumps over the lazy dog.
</xmp>
After the example text, we revert to the default again.
<h3>Glossary</h3>
Now lets us try out a glossary.
<dl>
<dt>Glossary<dd>A list of definitions of terms. Each term is given in a left-hand column, with a longer textual definition being given in a right-hand column.
<dt>Term<dd>A word or phrase being defined.
<dt>Definition<dd>A sentences or sentences which define the term. the definition can wrap around in the second column, but the term can't wrap around in the second column.
</dl>
And after that dazzling display of formatting, how about an ordered list:
(We support it as an unordered list)
<ol>
<li>This is the first element of an ordered list
<li>This is the 2nd element of an ordered list. This element contains more text than one would normally expect to fit onto a line.
It should wrap around onto the next line(s) with the left margin still indented.
<li>This is the 3rd element of an ordered list
<li>This is the 4th element of an ordered list
</ul>
And now, how about an unordered list:
<ul>
<li>This is the first element of an unordered list
<li>This is the 2nd element of an unordered list
<li>This is the 3rd element of an unordered list
<li>This is the 4th element of an unordered list
</ul>
Now let's try a "LISTING" section.
<LISTING>
123456781234567812345678123456781234567812345678123456781234567812345678123456781234567
! ! ! ! ! ! ! ! ! ! !
Column: First Second Third Fourth Fifth Sixth Seventh Eighth Ninth Tenth
Index: 1 2 3 4 5 6 7 8 9 10
Junk: The Quick borwn fox jumps over the lazy dog again!
</LISTING>
This is the end of the test file.
This sample test file is the earliest demonstration of what elements and entities existed in this first
and oldest version of HTML. It still has <ol> and the <p> tag is
still unary, but this file contains the oldest online html examples of <xmp> and
<listing>, albeit only as demonstrations. It also contains the dictionary tags
<dl>, <dt>, and <dd> which otherwise don't seem
to be seen until the next version of HTML, though perhaps a few files from this era but modified later
might possibly have contained these tags. Most unusual is that this file contains the only known instances
of any <HPn> tags, and only as a demonstration. Though mentioned in the documentation
for the next version of HTML, these tags would go either virtually or entirely unimplemented until much
later, and not in that form but in the more familiar <I> and <B>
tags. Even here, only <HP2> actually occurs in the text, which is represented by
putting its content in bold. Conspicuously absent, however, are any <plaintext>
or <address> or any of <h4> through <h6>. Also
note the specific declaration that two carriage returns (or a blank line) also constitutes the
equivalent to the <p> tag, as an archaic usage from the SCRIPT language.
Ted Nelson and Xanadu - Windows Internet Explorer
Ted Nelson originally invented the word"hypertext" for "non-sequential writing". His long-standing interest in all things related to HT became the Xanadu project. The Xanadu Operating Company is now owned by Autodesk, but the project continues.
He describes himself, his colleagues, his philosophy and his project in "Literary Machines" which is an attempt to put his hypertext thoughts onto paper. He publishes it himself (I have a copy of LM 90.1 -TBL). This is essential reading as background, enthusiathm and ideas on hypertext. (It includes also the text of Vannevar Bush's "As we may think". This is an article published in 1945 which suggests that an automated "MEMEX" (memory extension) would allow human memory to be augmented by mechanical means.)
Xanadu has many interesting concepts: for example, Nelson has tackled the problem of generating unique names for new documents such that they can be found, and the Xanadu project will aim to attribute royalties to the author of a work whenever it is retrieved across the network.
Ted also publishes a video of himself explaining his ideas.
T.H.Nelson, Mindful Press 3020 Brudgeway Suite 295, Sausolito CA 94965, phone 415/331-442.
<title>Ted Nelson and Xanadu</title> <h1>Ted Nelson and Xanadu</h1> <a name=nelson>Ted Nelson</a> originally invented the word<a href=Terms.html#Hypertext>"hypertext"</a> for "non-sequential writing". His long-standing interest in all things related to HT became the Xanadu project. The Xanadu Operating Company is now owned by Autodesk, but the project continues. He describes himself, his colleagues, his philosophy and his project in "Literary Machines" which is an attempt to put his hypertext thoughts onto paper. He publishes it <a href=#Mindful>himself</a> (I have a copy of LM 90.1 -TBL). This is essential reading as background, enthusiathm and ideas on hypertext. (It includes also the text of Vannevar Bush's "As we may think". This is an article published in 1945 which suggests that an automated "MEMEX" (memory extension) would allow human memory to be augmented by mechanical means.) Xanadu has many interesting concepts: for example, Nelson has tackled the problem of generating unique names for new documents such that they can be found, and the Xanadu project will aim to attribute royalties to the author of a work whenever it is retrieved across the network. Ted also publishes a video of himself explaining his ideas. <a name=Mindful>T.H.Nelson, Mindful Press 3020 Brudgeway Suite 295, Sausolito CA 94965, phone 415/331-442.</a>
This file contains the oldest surviving <a name=X>
instance, though this is probably almost as old as the href attribute. I
have to wonder what happened with the address since almost every part contains a
spelling error, "Brudgeway" for "Bridgeway," "Sausolito" for
"Sausalito," and a six-digit phone number. Someone was obviously having a bad
day. Notice also how the <address> element was not used, though
plainly it would have belonged here, thus indicating that it does not stem from this
early period. For yet another time, double carriage returns are again used to serve
as paragraph breaks.
Tutorial 8 - ECHT90 - Windows Internet Explorer
This was rather badly presented, though I got some ideas here: simple grammars may help in reading and identifying parts of texts that are important for linking, and therefore relatively simple tools can be built to transform classical, linear texts into hypertexts, provided the author has been reasonably good at expressing himself. As it became clear to me (RC) during the conference that dynamic construction of links is necessary, it will indeed be very useful to have such tools, however imperfect, that help find important text sequences. Two problems were addressed:
Conversion is defined as the process which allows segmentation of the text into coherent units in three stages:
Information units have the following structure:
It was stressed that conversion should not imitate, but add value for the new medium. As this means understanding the subject matter, and therefore is a cognitive process, it can today only be done wiht the help of a human author. However, artificial intelligence techniques using the concepts of frames and inheritance can help a lot. Even simple context-free grammars to specify noun-groups can be succesfully used to identify for example the label part of an information unit.
In well-structured linear texts (and we should hope that most texts worth converting are also well-written) syntagmatic relations (next-passage, previous-passage, ...) can be detected fairly easily.
Paradigmatic relations provide more information and can be detected using knowledge bases (share-concept, have-same-features, have-same-info, ...).
using these techniques, one can let the user query, and produce eg. an abstract which is a function of the query in real time. For example, an article on "Amiga peripherals" would produce a short abstract for a query looking for "microcomputer", but a longer one for a query looking for "Amiga" or for "peripherals".
This seminar showed once more that dynamic treatment of text is of great importance to the user who actually wants to make the machine locate information rather than browsing through it himself until he stumbles upon what he's looking for.
<title>Tutorial 8 - ECHT90</title> <h1>Machine aided construction of hypertext bases</h1> <a href=People.html#Kuhlen>Rainer Kuhlen</a> <p> This was rather badly presented, though I got some ideas here: simple grammars may help in reading and identifying parts of texts that are important for linking, and therefore relatively simple tools can be built to transform classical, linear texts into hypertexts, provided the author has been reasonably good at expressing himself. As it became clear to me <a href=Authors.html#Cailliau>(RC)</a> during the conference that dynamic construction of links is necessary, it will indeed be very useful to have such tools, however imperfect, that help find important text sequences. Two problems were addressed: <ul> <li> using existing texts as a basis for constructing hypertexts: splitting the linear texts up into nodes and adding the links. It was shown how some simple schemes can go a long way towards such a conversion in a computer-assisted fashion, by algorithms which propose splits and links. <li> generating aids in presentation dynamically, such as tables of contents, glossaries, indexes. For example, extracting those terms that can be looked up in a glossary dynamically rather than by static identification at authoring time. </ul> <p> Conversion is defined as the process which allows segmentation of the text into coherent units in three stages: <ol> <li> identification of coherent units <li> reconstruction of cohesive boundness (semantically closed units are sought) <li> transformation / integration of the units. </ul> </p> <p> Information units have the following structure: <ol> <li> Contents: <ul> <li> label (name or title of the unit) <li> conceptual reference (index term) <li> condensation reference (abstract) <li> informative part </ul> <li> Functions: <ul> <li> information functions (links, paths, orientation means) </ul> </ol> <p> It was stressed that conversion should not imitate, but add value for the new medium. As this means understanding the subject matter, and therefore is a cognitive process, it can today only be done wiht the help of a human author. However, artificial intelligence techniques using the concepts of frames and inheritance can help a lot. Even simple context-free grammars to specify noun-groups can be succesfully used to identify for example the label part of an information unit. </p> <p> In well-structured linear texts (and we should hope that most texts worth converting are also well-written) syntagmatic relations (next-passage, previous-passage, ...) can be detected fairly easily. </p> <p> Paradigmatic relations provide more information and can be detected using knowledge bases (share-concept, have-same-features, have-same-info, ...). </p> <p> using these techniques, one can let the user query, and produce eg. an abstract which is a function of the query in real time. For example, an article on "Amiga peripherals" would produce a short abstract for a query looking for "microcomputer", but a longer one for a query looking for "Amiga" or for "peripherals". </p> <p> This seminar showed once more that dynamic treatment of text is of great importance to the user who actually wants to make the machine locate information rather than browsing through it himself until he stumbles upon what he's looking for. </p>
This is the first file that shows the closing </p> tag. Does this represent a
change from how <p> was handled in the previous year, or was <p>
always a containing element with the closing tag optional as it has been from HTML 2 onwards? This
file shows yet another hand-entered error in that a closing </ul> tag occurs where
a closing </ol> tag would have rendered the file correctly. Could this mistake
reflect the beginning of the trend away from the use of <ol>? This is the last and
most recent of these files in which the <ol> tag would be seen, until the time that
its reappearance is recommended in late 1992.
Databases, Indices, and normative knowledge
D. Schwabe, B. Feijo', W. Krause
<a name=pap04>Databases, Indices, and normative knowledge</a> <h1>Hyperbase</h1> <a href=People.html#Streitz>N. Streitz</a> <h1>Hyperindices: a novel aid for searching in Hypermedia</h1> <a href=People.html#Bruza>P. Bruza</a> <h1>Intelligent hypertext for normative Knowledge in Engineering</h1> <a href=People.html#Schwabe>D. Schwabe, B. Feijo', W. Krause</a>
This is the first of five files from this group which all lack a <title>
but instead seem to enclose a title in the form of an <a name=X>
phrase. Again, I have to wonder if these files were once part of a larger file, thus using
the name parameter as a link destination, or were they experimenting with using
this instead of <title>, perhaps either to phase it out or else limit to
much more rare occasions. Typically, the <title> was meant to serve as a
kind of "node name" since the destination of a link could be a file (node) or a portion
of a file. <a name=X> could have also been seen as a kind of
node name, and there may have been some experiments going on with using this alternate sort
of node name even for the whole file instead of <title>.
R. Furuta, P. Stotts
<a name=pap06>Turning Text into Hypertext</a></title> <h1>Hierarchy, composition, scripting langueages and translators for structutred hypertext</h1> <a href=People.html#Furuta>R. Furuta</a>, P. Stotts <h1>Links and structures in hypertext databases for law</h1> <a href=People.html#Wilson>E. Wilson</a> <h1>An apprentice that discovers hypertext links</h1> <a href=People.html#Bernstein>M. Bernstein</a>
Here is another file with <a name=X> substituted for
<title>. In this one, see the closing </title>
tag, perhaps left in by mistake, or else not completed properly.
What is specific about user interfaces for hypertext systems?
Accordig to one opinion, hypermedia will wipe out all the issues about user interfaces. This was not shared, but the discussion went in no particular direction and failed to reach any conclusion.
<a name=pan6>What is specific about user interfaces for hypertext systems?</a> Accordig to one opinion, hypermedia will wipe out all the issues about user interfaces. This was not shared, but the discussion went in no particular direction and failed to reach any conclusion.
Here is another file with <a name=X> substituted for
<title>, and the last surviving instance of the double carriage return to
be used as a paragraph break from this period.
Paper 1 - Windows Internet Explorer
Peter Brown Messages were:
<title>Paper 1</title> <h1>Keynote Address: Assessing the quality of hypertext documents</h1> <a href=People.html#Brown>Peter Brown</a> Messages were: <ul> <li> We need better authors more than anything else now. Authors are not yet used to the medium. Existing texts can be put into hypertext, but the construction of new material, produced explicitly for the hypertext medium, requires different ways of working and presenting ideas. Only a handful of authors today have achieved significant production. <li> Because hypertexts are active (scripts can run when links are traversed), they may be the next feeding ground for computer viruses. They can also be present in the form of false information, or of fraudulent information posing for the real thing. <li> How can you trust information contained in hypertexts? </ul>
Yet, as seen here, <title> is still alive and well, evidently meant to
be used at least some of the time.
Formal models and query languages
This was somewhat of a disaster: the mathematicians and theoreticians are scrambling to put some formalisms into hypertext ideas after the facts. Without exception, they treat only simple, clean cases, use a lot of formal notation that is cumbersome and lengthy, and finally get nowhere. While I appreciate the need for formal treatment of informatics concepts, I think it is rather useless to go to great lengths in an early stage (as an analogy: all the time spent by theoreticians on programming language formalisms is largely wasted in a world where C is unfortunately what people do).
Chaired by Tim Oren. He stated that linking and querying over networks is now seen as an important issue for ISO standards in hypertext.
F. Afrati, C. Koutras Claimed that by 1995 object-oriented databases will be available, and that hypertexts will be built on top of them. The formal model presented was based on work with Dexter and Z (from B. Meyer of Eiffel).
C. Beeri, Y. Kornatzky
He was concerned with the structure, not the contents: eg. he addressed such problems as "find all nodes connected to this node in not more than two hops".
Modelled the retrieval process task as an inference process, defined Metawebs. I could not keep my eyes open, but it was not all his fault...
One of my(RC) impression is this: when we had only pure text files (also wrongly called ASCII files), we could search with an editor to find occurences of words. This search would be carried out with 100% precision: the word either is there or it is not. Of course, if the word is misspelled, then it will not be found. So in fact fuzzy search will help find spots of interest that are overlooked by precision searches. In hypertexts, we need even more sophisticated ways of finding the material that we want: the spot of interest may contain only words that are related to the subject. (There is the example of looking for "aircraft crash" which should not overlook an article about "commercial jet wreckage"). But whereas in precision searches, it was relatively easy for the common user to learn how to formulate thesearch, this may be more difficult for intelligent searches. Is it going to be easier and better to look in hypertexts or is it going to be just like now when you know someone who knows where to point you to?
<a name=pap03>Formal models and query languages</a> <p> This was somewhat of a disaster: the mathematicians and theoreticians are scrambling to put some formalisms into hypertext ideas after the facts. Without exception, they treat only simple, clean cases, use a lot of formal notation that is cumbersome and lengthy, and finally get nowhere. While I appreciate the need for formal treatment of informatics concepts, I think it is rather useless to go to great lengths in an early stage (as an analogy: all the time spent by theoreticians on programming language formalisms is largely wasted in a world where C is unfortunately what people do). </P> <p> Chaired by Tim Oren. He stated that linking and querying over networks is now seen as an important issue for ISO standards in hypertext. </p> <h1>A hypertext model supporting query mechanisms</h1> <a href=People.html#Afrati>F. Afrati</a>, C. Koutras Claimed that by 1995 object-oriented databases will be available, and that hypertexts will be built on top of them. The formal model presented was based on work with Dexter and Z (from B. Meyer of Eiffel). <h1>A logical query language for Hypertext systems</h1> <a href=People.html#Beeri>C. Beeri</a>, Y. Kornatzky <p> He was concerned with the structure, not the contents: eg. he addressed such problems as "find all nodes connected to this node in not more than two hops". </p> <h1>A model for Hypertext based information retrieval</h1> <a href=People.html#Lucarelli>D. Lucarelli</a> <p> Modelled the retrieval process task as an inference process, defined Metawebs. I could not keep my eyes open, but it was not all his fault... </p> <p> One of my<a href=Authors.html#Cailliau>(RC)</a> impression is this: when we had only pure text files (also wrongly called ASCII files), we could search with an editor to find occurences of words. This search would be carried out with 100% precision: the word either is there or it is not. Of course, if the word is misspelled, then it will not be found. So in fact fuzzy search will help find spots of interest that are overlooked by precision searches. In hypertexts, we need even more sophisticated ways of finding the material that we want: the spot of interest may contain only words that are related to the subject. (There is the example of looking for "aircraft crash" which should not overlook an article about "commercial jet wreckage"). But whereas in precision searches, it was relatively easy for the common user to learn how to formulate thesearch, this may be more difficult for intelligent searches. Is it going to be easier and better to look in hypertexts or is it going to be just like now when you know someone who knows where to point you to? </p>
Here is another file with <a name=X> substituted for
<title>. Notice again the occurrence of the closing
</p> tag, and how one of them is capitalized, again hand-entered.
W. Irler, G. Barbieri
Gestures are used to browse in button-less hypertexts. Anchors are not visible in the text, but the buttons are "hidden" on a secondary page which shows you the local route map (ie. where you can go to directly from here). Some novel ideas.
A dynamic/static assignment of affinity of the nodes is computed, which then leads to the presentation of a navigation view. Affinity is by context.
F. Biennier, M. Guivarch, J.M. Pinon
She stated: "While browsing, users forget their goals...". Many of us have perceived this while looking something up in an illustrated dictionary... The user's profile should be integrated in the query. Neural nets have no a-priori logical rules for the query.
<a name=pap08>Navigation and Browsing</a> <h1>Non-intrusive Hypertext Anchors and individual Colour Markings</h1> <a href=People.html#Irler>W. Irler</a>, G. Barbieri <p> Gestures are used to browse in button-less hypertexts. Anchors are not visible in the text, but the buttons are "hidden" on a secondary page which shows you the local route map (ie. where you can go to directly from here). Some novel ideas. </P> <h1>SaTellite: hypermedia navigation by affinity</h1> <a href=People.html#Pintado></a>X. Pintado, D. Tsichritzis <p> A dynamic/static assignment of affinity of the nodes is computed, which then leads to the presentation of a navigation view. Affinity is by context. </p> <h1>Browsing in hyperdocuments with the assistance of a neural network</h1> <a href=People.html#Biennier>F. Biennier</a>, M. Guivarch, J.M. Pinon <p> She stated: "While browsing, users forget their goals...". Many of us have perceived this while looking something up in an illustrated dictionary... The user's profile should be integrated in the query. Neural nets have no a-priori logical rules for the query. </p>
Here is the last file with <a name=X> substituted for
<title>. Notice again the occurrence of the closing
</p> tag, and how one of them is capitalized, again hand-entered.
Documentation Ideas - Windows Internet Explorer
We need to consider
Require a simple and short users guide, which includes the basic description of the program, how to use it, and how to install it.
Require the internals of the program, in order to debug, if in the future, problems arise. They need to have an overview of the program, mentioning any departures from normal practice. They need to have details of the structural layout of the program and information concerning any setups required, aswell as a list of files which are needed to be linked into the program, and details of which operating system should be used.
Documentation should be kept simple and short.
<title>Documentation Ideas</title> <h1>Audience</h1> We need to consider <ul> <li>- Who the audience are. <li>- What they need to know in order to use the program. <li>- What we can assume they know already (nothing?). <h2>Users</h2> Require a simple and short <a href=UsersGuide.html> users guide</a>, which includes the basic description of the program, how to use it, and how to install it. <h2>Maintainers</h2> Require the internals of the program, in order to debug, if in the future, problems arise. They need to have an overview of the program, mentioning any departures from normal practice. They need to have details of the structural layout of the program and information concerning any setups required, aswell as a list of files which are needed to be linked into the program, and details of which operating system should be used. <p>Documentation should be kept simple and short.
This file was obviously merely opened at a later date, but not converted to the then current version of HTML. They seem to have been uncertain that the unordered list element would add bullets, so lines were added. They also forgot to close the list, or else deleted it by accident.
What is an Index, anyway? - Windows Internet Explorer
The Century Index (1914, about 5kg) in Jery Slatzer's office says an index is from the Latin index meaning "a discoverer, informer, spy" or of things "an indicator, the forefinger, title, superscription"
I like the "discoverer, informer" part. That is what we mean by a server of which you can ask a question.
An index can be that which points,- like an index finger, or the index into an array. This emphasises that the index need not contain the data (wheras a databse usually does)
What we really mean by index in the W3 world is any algorithm taking human input and generating a view as a function of that input. There need not be a database, for example in the square-root server]
Tim<title>What is an Index, anyway?</title> <h1>Index</h1> The Century Index (1914, about 5kg) in Jery Slatzer's office says an index is from the Latin index meaning "a discoverer, informer, spy" or of things "an indicator, the forefinger, title, superscription" <p> I like the "discoverer, informer" part. That is what we mean by a server of which you can ask a question. <p> An index can be that which points,- like an index finger, or the index into an array. This emphasises that the index need not contain the data (wheras a databse usually does) <p> What we really mean by index in the W3 world is any algorithm taking human input and generating a view as a function of that input. There need not be a database, for example in the square-root server] <address>Tim</address>
Except for the late date and the use of an <address> element,
this file shows evidences of being from the old period, and hence is included here.
Perhaps it was opened to add <address> to it? In any case, the
additional <address> element is the only thing that does not pass
validation using the html0.a DTD.
Overview of the Web - Windows Internet Explorer
There is no "top" to the World-Wide Web. You can look at it from many points of view. If you have no other bias, here are some ways of looking for information.
If you have to use a "top" node, we recommend either this node or the subject list. See also: About the W3 project.
<title>Overview of the Web</title> <h1>General Overview</h1> There is no "top" to the World-Wide Web. You can look at it from many points of view. If you have no other bias, here are some ways of looking for information. <DL> <DT><a href=bySubject/Overview.html>by Subject</a> <DD>A classification by subject of interest. Incomplete but easiest to use. <DT><a href=ByAccess.html>by Type</a> <DD>Looking by type of service (access protocol, etc) may allow to find things if you know what you are looking for. </DL> If you have to use a "top" node, we recommend either this node or the subject list. See also: <a href=../WWW/TheProject.html>About the W3 project</a>.
This file shown was opened later (though obviously originally created during this
early period). What is not clear is whether this was done in order to add the
<DL>, <DT>, and <DD> elements
or for some other reason. Note how the dictionary elements are all in upper case where
all else is in lower case, showing it to have been most probably added by a later hand,
or else added in the early period when these elements were first being tested.
Help for W3 software - Windows Internet Explorer
Which program are you using for which you want online help?
See also the W3 server user manual. For other questions, browse from the W3 project page.
<title>Help for W3 software</title> <h1>Help</h1> Which program are you using for which you want online help? <dl> <dt><a href=LineMode/Defaults/QuickGuide.html>Line Mode Browser</a> <dd>Using the line mode browser, select an option with a number and press RETURN <dt>Viola <dd>Fpr help on Viola, just press the question-mark (?) icon near the top right-hand corner. <dt><a href=NeXT/WorldWideWeb.html>NeXTStep</a> <dd>To select help with this browser, use Help from the Info menu or select this option wit the mouse (double click). <dt><a href=http://slacvx.slac.stanford.edu:80/MidasWWW/v10/overview.html> MidasWWW</a> <dd>For help on this browser, select this option with the mouse. </dl> See also the <a href=Daemon/User/Guide.html>W3 server user manual</a>. For other questions, browse from the <a href=TheProject.html>W3 project page</a>.
Though only a few hours later in the day than the previous, this time the later
hand remembered to put the <dl>, <dt>, and
<dd> tags in lower case, which was consistent with the rest of the file.
This file, "htmlsource0.a.html," is HTML 4.01 Strict
compliant.
This file also validates without error as
CSS level 2.1.