Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!brunix!ted
From: ted@brunix (Tony Davis)
Newsgroups: comp.org.ieee
Subject: Hypertext format (Re: Standards on Standards)
Message-ID: <10766@brunix.UUCP>
Date: 19 Jul 89 05:28:04 GMT
References: <214@sierra.stanford.edu>
Sender: news@brunix.UUCP
Reply-To: ted@bimini.UUCP (Tony Davis)
Distribution: na
Organization: Brown University Department of Computer Science
Lines: 87

WARNING, if this turns into a discussion it should be moved to another
news group; it may not be captivating to all of ieee and it is certainly
of wider interest than ieee only.  Can anybody suggest one?

In article <214@sierra.stanford.edu> neff@sierra.UUCP (Randall B. Neff) writes:
> [ Good discussion of the silliness of using non-standard MS-DOS hypertext ]
> [ program for standards distribution. ]
>Once the file format is defined, independent groups can write their own
>hypertext readers, in a similar fashion to the different USENET news readers
>available and the different X window managers being used and developed.
>
>The first level file format requires:
>	labels for the pages and page breaks.
>	define text buttons and targets (page, line, column).
>	editor for the format (GNU EMACS macros?).
>
>The second level file format requires:
>	color graphics (X window primatives?).
>	graphic buttons.
>	font names and exact formatting (LaTeX?).
>	graphic / page layout editor.
>
>The third level file format requires:
>	embedded `programming language'.
>	editor / debugger for language.
>
>Randall Neff@anna.stanford.edu

Most of the above should NOT go into a hypertext standard.  The most
important guidelines I have heard so far:

	Hypertext is NOT a text editor.
	It's useless to put 'text editor like' capabilities in a hypertext
format because this will quickly cause the standard to be ignored ("What,
we can't use our outline fonts and flexible layout format since they
aren't specified in your standard?  Fine, we won't use your standard.")
Forcing people to use the same or limited set of text editor(s) to use
a hypertext standard will kill the standard rather than the editors.

	Hypertext is NOT a graphics interface.
	Same argument as above.

These two guidelines eliminate all of levels two and three above and
5/6 of level one.  One more guideline then some discussion of what
a hypertext standard SHOULD do:

	A hypertext format may be a 'transportation only' format.
	One cannot and should not want to dictate a document format;
it will be ignored (Guideline 1 from above).  Even worse, resident
hypertext documents may have no hypertext information in them at all.
Hypertext link information can be kept in a document-external database
with many advantages.  The database can support multiple independent
webs of links on the same document set.  This and other enticing
features are easily possible with the 'external link approach' without
thinking of every feature beforehand. They are strong arguments for
separation of hypertext links from the source documents, although the
links must go with the documents for distribution.  Separating the links
from the document is the enabling power which will allow a variety of
"hypertext readers".

The minimum hypertext standard simply provides a format for specifiying the
source and destination of links.  This requires a 'document format independent'
means of  specifying the source and destination locations within documents.
'Format independent' may mean that it cannot be in terms of "page, line,
column".  What is a 'format independent' page break?  Are columns characters
or pixels?  What is the line break character (or symbol, or directive)?  Both
source and destination must be specified to allow bidirectional links.
Bidirectional links are convenient and necessary for many features;  how does
one delete all the links coming into a document when that document goes away?

After links have been specified, types of links come under consideration.
This might best be supported in the format by support for symbolic names
of link types.  With this addition, acceptability and usefulness of the
standard already start fading to a fuzzy issue so I won't elaborate.

My postion (though not original with me) is that we want hypertext to become
as common as cut, copy, and paste are in Macintosh applications.  Originally
only a few applications had them, but they spread because of their incredible
usefulness and a 'document format independent' way of doing them.  Hypertext
can go the same route if we avoid tying it up in monolithic, application-based
standards.  Witness Core graphics which was surplanted by GKS which was
surplanted by Phigs which was surplanted by Phigs+ which was surplanted by
HOOPS?  In summary, hypertext is a feature, not an application.


Tony Davis
ted@cs.brown.edu