Xref: utzoo comp.org.ieee:135 comp.text:4426 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!arc!steve From: steve@arc.UUCP (Steve Savitzky) Newsgroups: comp.org.ieee,comp.text Subject: Re: Hypertext format (Re: Standards on Standards) Summary: Hypertext standard wanted Message-ID: <472@arc.UUCP> Date: 19 Jul 89 17:44:23 GMT References: <214@sierra.stanford.edu> <10766@brunix.UUCP> <410@arc.UUCP> Reply-To: steve@arc.UUCP (Steve Savitzky) Followup-To: comp.text Distribution: na Organization: Advansoft Research Corp, Santa Clara, CA Lines: 113 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 Santa Clara, CA 95054 | May the Source be with you!