ted@brunix (Tony Davis) (07/19/89)
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
malcolm@Apple.COM (Malcolm Slaney) (07/19/89)
In article <10766@brunix.UUCP> ted@bimini.UUCP (Tony Davis) writes: >..... >The minimum hypertext standard simply provides a format for specifiying the >source and destination of links. >..... I don't think hypertext is going to be successful with just smart links. I've just about finished writing a Hypercard introduction to a large database of auditory demonstrations/illusions. The hardest part of this endeavor has not creating the links but designing the screen layout and the user interface. Linear text is easy to present. It doesn't take much imagination to figure out how to present a string of characters on the screen. But as soon as you add multiple dimensions to the document it becomes much harder to organize. Trying to make it clear to the user (reader) should be the most important goal. For a good introduction to this problem read Danny Goodman's "The Complete Hypercard Handbook." He argues, among other things, that a graphics designer should be part of every hypertext design effort. The user interface is the hard part! And as far as IEEE is concered....I applaud their efforts! I don't know anything about the hypertext system they chose but it's time to stop using just linear text. I want to write papers with live equations where the user can plug their parameters into my equations and see the graphs change. I want to be able to put an animated figure into my paper and when the user asks for it the figure starts moving. I'm doing work on pitch perception. I want my audio illustrations to be part of the paper and not on a seperate cassette tape that can get lost and is not convenient. All of this will help my readers understand the work I am doing. Malcolm Slaney ATG Speech and Hearing Project
steve@arc.UUCP (Steve Savitzky) (07/20/89)
In article <10766@brunix.UUCP> ted@bimini.UUCP (Tony Davis) writes: >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? comp.text? This ties in with the discussion of SGML taking place in that group. See followup line above. There was also some discussion of this in comp.software-eng, where I posted a followup to Randall Neff's article. >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. ^^^^^^^^^^^^^^^^^^^^^^ document structural components >> define text buttons and targets (page, line, column). ^^^^^^^^^^^^ links and active objects >> editor for the format (GNU EMACS macros?). ^^^^^^^ SAMPLE front end >> >>The second level file format requires: [graphics, fonts, etc. -- list omitted] >> >>The third level file format requires: [programming language with editor & debugger] >> >>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. [argument omitted] > 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. [more stuff omitted, arguing that links should be in a separate file from the document] I think that separating linkage from document information should be an option, not a requirement. I agree completely with Tony that hypertext is not an editor or an interface, but a hypertext standard MUST be capable of REPRESENTING any combination of text, graphics, sound, and other information. It *isn't* just links. Links are the connections between objects; you have to be able to specify the objects, too! >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"... ^^^^^^^^ definitely means Hypertext should specify a document's STRUCTURE, rather than its format. In other words, a Hypertext is a collection of OBJECTS. SUMMARY I would like to see a hypertext standard that is: o Non-proprietary o Object-oriented. It should be possible for ANY object to have ANY collection of attributes. This makes it easy to represent any document structure, including graphics, active buttons, etc. o Capable of "linking in" objects that are contained in arbitrary external files -- this handles Tony's desire for separable link files. o Includes a way of specifying executable objects (programs) as abstract syntax trees (i.e. collections of objects). The ability to include programs is important: o It allows hypertexts that contain active objects such as buttons to be described and transported. o It allows data in arbitrarily-structured external files to be included in a hypertext by including a program that can parse the file. Such structured external files include: SGML documents, tar archives, and of course news and mail archives. o Includes a portable sample implementation, including a library of routines for manipulating hypertexts, and a (possibly very crude) sample front end. I'm thinking of the X windowing system as a good example of this. The easier a standard is to implement, the more popular it will be. What I want may be closer to an object-oriented database/file system/ programming environment than to a simple "file format". >Tony Davis >ted@cs.brown.edu -- Steve Savitzky | steve@arc.uucp | apple.com!arc!steve ADVANsoft Research Corp. | (408) 727-3357(w) / 294-6492(h) 4301 Great America Parkway | #include<disclaimer.h> Santa Clara, CA 95054 | May the Source be with you!
blackje@sunspot.crd.ge.com (Emmett Black) (07/22/89)
how about "alt.hypertext" ... perhaps we should move this discussion there, and make it something other than a hypercard forum. (bump those folks to comp.sys.mac.hypercard :-) how about it? --Emmett J.E.Black; GE Research/K1-3C26; Schenectady, NY 12345 blackje@crd.ge.com
camp@m2.csc.ti.com (Clyde Camp) (07/26/89)
Neither the Hypertrans(TM) people nor the IEEE people can at this time
communicate directly over the net and I have received their permission
to transmit their responses to the recent traffic concerning the POSIX
Hypertext project, of which they have been sent hardcopies.
The following is a three part response, first from me personally, second
from the Hypertrans people and third from the IEEE Standards Office.
Part #1 (Clyde Camp)
====================
Before I proceed, let me introduce myself. My name is Clyde Camp. I
work for Texas Instruments in the Computer Science Center but have
been spending about half my time for the last 8 years or so working
with the IEEE and Computer Society Standards organizations. I
currently hold several voluntary positions within the IEEE including
the chair of the Microprocessor Standards Committee which sponsors
around 30 bus and language standards. I am in no way associated with
the people doing the TI Hypertrans(TM) product and in fact initially
learned about it through the IEEE during a discussion with Jay Iorio
and Judy Gorman on an entirely different matter. Since then, I have
been supporting it and helping to coordinate things in a minor way
(including sending this response.) From a standards standpoint, I
personally think that it is an excellent idea.
I was somewhat aghast at seeing the negative response to an experiment
that came about due to a large number of requests to the IEEE
Standards Office to deliver standards in a media other than hardcopy.
I assure you that the standards office is extremely interested in any
comments any of you may have and that they have no wish to spend a lot
of money developing a delivery mechanism that no one wants to use.
Their choice of MS-DOS as the first delivery vehicle for the POSIX
test was driven by several factors, not the least of which was that
there are a huge number of DOS machines using 5.25-in floppies out in
the workplace - an unpalatable fact for UNIXphiles and MACphiles, but
true none-the-less.
In any case, you can get mail to either Jay or Judy in either of
the following ways:
1) I'll be glad to forward it to them directly since I have access to
both the net and the e-mail system they use.
2) You can send U.S. Mail to either Jay Iorio (who is coordinating
the POSIX experiment) or Judy Gorman (who is in charge of all
publications) at:
IEEE Standards Office
445 Hoes Lane, P.O.Box 1331
Piscataway, NJ 08855-1331
They are more receptive (as I am) to rationally phrased arguments,
either pro or con, than to mere flames.
To clear up a few possible misconceptions:
- There is absolutely no intention by the IEEE to convert completely
to Hypertext. Printed versions will always remain available - after
all, quite a few people do not have access to a computer of any
type; sad but true :-).
- The current POSIX experiment is just that - an experiment. The
recent demonstration to the POSIX working group in San Jose
generated more than suffficient positive response to continue. This
does NOT mean that MS-DOS is the only delivery vehicle - see the
HYPERTRANS Response in Part #2. There will be other experiments
with other standards and other delivery mechanisms.
- Exactly which delivery vehicles ARE used by the IEEE will be
determined primarily by demand, although funding and copyright
issues must also be considered. Funding comes from two sources -
from budget requests to the IEEE (and therefore from IEEE member
dues) and from profit from sales of standards. The current IEEE
policy is that the Standards Office must be essentially self
sustaining. Profits, as such, are plowed back into increased user
services.
- One of the goals of the IEEE Standards Office is to provide
increased functionality, not just machine readable copy. This is
especially important for large, complex standards which cover
multiple documents.
To answer a few specific questions from the net that I couldn't just
let pass by:
>>From: neff@sierra.Stanford.EDU (Randall B. Neff)
>>Actually, the current implementation plan of issuing IEEE standards in
>>machine readable form could be considered, in one sense, as an admission
>>of failure (or just lack of success) of the IEEE standards group.
>> ...
>> An alternative question might be: why aren't IEEE standards more
>> popular?
They are. It is a multi-million dollar business and it wouldn't be if
the product wasn't needed. That doesn't meen that *everyone* needs
them, however IEEE standards are recognized internationally as
representing a broad consensus view and as such, they are widely used in
industry, in government procurement specifications and as starting point
documents for international standards efforts. The delivery of a
machine readable form is in response to many requests; but even given
that a machine readable form was available for any machine you wanted to
run on, I would bet that printed version sales would exceed machine
readable version sales for a LONG time.
Incidently, there is an effort underway (P996 - Chaired by Scott
Hopkinson at 714/662-5600) to standardize the PC-bus architecture.
>>[Tony Davis ted@cs.brown.edu]
>>[ long discussion on pros and cons of Hypertext in general]
>>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.
>>
>>[ Steve Savitzky | steve@arc.uucp | apple.com!arc!steve ]
>>I agree completely with Tony that hypertext is not an editor or an
>>interface, but a hypertext standard MUST be capable of REPRESENTING
>>any combination of text, graphics, sound, and other information. It
>>*isn't* just links. Links are the connections between objects; you
>>have to be able to specify the objects, too!
>>
>>Hypertext should specify a document's STRUCTURE, rather than its
>>format. In other words, a Hypertext is a collection of OBJECTS.
I definitely agree with Tony's last sentence, but Steve is also right.
One way to prevent future misuse is to proactively write an
appropriate standard which achieves your (and hopefully the
industry's) goals of a document format independent standard and solve
the problem before it becomes a problem. I don't personally know
enough about hyperxxxx to technically judge whether or not this is
feasible. But I do know that while the initial gut reaction of many
people is "we don't need a standard", the long term usefulness of
standards overwhelms the problems. As an example, there were MANY
MANY objections and bitter discussions and counter proposals over the
IEEE Floating Point Standard and yet it is perhaps one of the most
widely used. If anyone is interested in a standard in this area, I
will be happy to discuss what is involved offline. The MSC would be
glad to sponsor such an effort, but it needs a `champion'.
>>Is there anyone from IEEE listening, or are we all just flaming in the
>>wind?
>>I just handed a paper copy of the entire discussion to Ken Anderson (the
>>president of the IEEE computer society). He said that he will forward it
>>to the right people. The Message-ID's of articles I have collected are
>>attached to the end of this note. If I have missed any, please send them
>>to Ken at
>> kra@demon.siemens.com
Actually, this is kind of interesting. A lot of people automatically
assume that the IEEE and Computer Society are essentially the same and
that addressing one is the same as addressing the other. Remember that
while the Computer Society is big, it is only a fraction of the IEEE's
total business which includes the Power Engineering Society, the Nuclear
Engineering Society and many others. Likewise, the Standards Office is
only a piece of the action - There's also publications (e.g.
transactions, Spectrum), member services, conferences, etc. It's like
any large company in that finding the right people to talk to is
sometimes a problem.
But in answer to your question, the right people in the IEEE Standards
Office (including the director, Andrew Salem) are now aware of this
discussion, as is the TI Hypertrans development program.
>>How about EtherNet, RS232C, RS422, RS423 ? CSMA CD, CSMA CA ?
>>IEEE 488? IEEE floating point numbers?
>>Nubus? VMEbus?
>>Aren't some of these IEEE standards?
The local area network standards are IEEE 802.x sponsored by the
Computer Society's Technical Committee on Computer Communications and
all fall under the 44 or so 802.x committees (Chair - Maris Graube.)
RSS232C, RSS422, RSS423 are EIA standards.
NuBus (IEEE 1196), VME (IEEE 1014), Multibus-I/II (IEEE 796/1296),
Futurebus (IEEE 896), Floating Point (IEEE 754), S100 Bus (IEEE 696), STD
Bus (IEEE 961) and others are IEEE standards sponsored by the Computer
Society's Microprocessor Standards Subcommittee (which I chair.)
IEEE 488 is sponsored by the IEEE Instrument and Measurement Society.
=============================================================================
PART #2 (TEXAS INSTRUMENTS HYPERTRANS DEVELOPMENT PROGRAM)
CLYDE, I APPRECIATE THE INTEREST AND ATTEMPTS TO HELP WITH THE FLACK GOING
ON ABOUT HYPERTRANS(TM). IF ANYTHING IS SAID OF THE NETWORK IT SHOULD
INCLUDE THE FOLLOWING INFORMATION:
HYPERTRANS(TM) IS NOT A STANDARD BUT A METHOD OF INFORMATION DELIVERY. IEEE
IS ENGAGED IN A PILOT STUDY. INTEREST WILL DICTATE WHERE IT GOES. BASED ON
INPUT FROM THE IEEE, MOST OPINIONS ARE VERY FAVORABLE.
THE HYPERTRANS (TM) PRODUCED DATA BASE INCLUDES BOTH AN ASCII FILE FOR
DOCUMENT TEXT AND A PROPRIETARY DATA STRUCTURE USED FOR NAVIGATION.
THE NAVIGATION SOFTWARE IS CALLED "DISCOVER:"(TM)
WE [also] HAVE A HYPERCARD STACK THAT CAN READ THE SAME DATA STRUCTURES.
WE HAVE ANOTHER INTERFACE CALLED "HYPERMEDIA" THAT IS CONSTRUCTED WITH
EMACS AND WILL BE AVAILABLE SOON FOR VMS AND UNIX BASED SYSTEMS.
THE HYPERTEXT ATTRIBUTES OF "DISCOVER:"(TM) AND ITS DATA BASE ALLOW FOR
FAST AND EASY BROWSING OF STRUCTURE AND CONTENTS, ADAPTIVE
INTERCONNECTIVITY BETWEEN RELATED DOCUMENTS (MORE BOOKS CAN BE ADDED TO
THE DATA BASE AND AUTOMATICALLY LINKED TO RESIDENT BOOKS), STORAGE OF
BOOKMARKS, TRAILS, AND HISTORY, FULL EXPANDED INDEX OF FUNCTIONS AND
FIELDS, AND SEARCH CAPABILITIES WITH CONTEXT MENU.
THE POSIX MATERIAL IS THE COPYRIGHT OF THE IEEE, AND TI IS MAKING NO CLAIM
TO THIS MATERIAL. THE IEEE WILL BE MARKETING AND SELLING THE SOFTWARE.
=========================================================================
PART #3 (IEEE STANDARDS OFFICE)
To: C.CAMP (CMP0011)
To: STANDARDS (IEE237)
From: STANDARDS (IEE237) Delivered: Wed 26-July-89 9:18 EDT Sys 134 (29)
Subject: POSIX
Mail Id: IPM-134-890726-083801243
7/26/89
------------
Dear Clyde,
Thanks for the communications. The Department's comments follow:
------------
The IEEE Standards Department is always interested in hearing
what potential users of standards need, and your comments on the
POSIX project may well prove helpful to us in our preparation of this
and other documents. We would like to clear up a few points:
One reason the IEEE Standards Department opted for Texas
Instruments' HyperTrans (tm) approach for this pilot project is the
portability of the database it generates. From the time of our
department's earliest discussions of hypertext and electronic
puiblishing in general, we have assumed that we would make
documents available for a variety of machines and operating
systems, depending on customer demand. TI assured us they could
accommodate this need. Another attraction of HyperTrans (tm) for
us is its automation of much of the linking process, without which
any such project would be prohibitively labor-intensive for us.
Our experience in the Standards Department is that by far most of
the people who submit or to whom we provide media work on
micros, and most use or can use 5.25-in 360K diskettes. In any event,
we'll support all common media, again depending on who needs
what.
The degree to which the user will be able to access the ASCII text
of the document is one issue being decided during the current beta
testing.
--IEEE Standards