Australian Computer Journal Vol. 25, No. 1 (1993) pp. 7-13.
Use of a Personal Workstation to Access Open Network
Services
Annotated February, 1999
Robert M. Colomb Cooperative Research Centre for Distributed Systems Technology Department of Computer Science and Electrical Engineering The University of Queensland, QLD 4072 Australia
Work performed while author was visiting the School of Computing Sciences, University of Technology, Sydney.
Abstract
Imagine that people have powerful, flexible workstations which can adapt to their work habits, and that they use an open distributed computing environment for information and computing resources. The user should have a uniform and seamless view of this computing environment. In addition, the user has a large investment in wordprocessors, spreadsheets and other personal productivity tools. It becomes natural then to argue that the network applications should interact with the user employing the user's personal productivity tools. We need to develop an abstract view of the capabilities of a User Interface Management System (UIMS), which is at a much higher level than graphics interface standards like X11, and also standards for the communication of documentation from an application to a UIMS. There must be standards for sharing models of data structures and definitions of the semantics of their various components. This paper sketches some requirements for the solution of these problems, based partly on data base technology and the design of persistent programming languages and access procedures for persistent object stores.
Key words and phrases: open distributed processing, user interface management
CR Categories: c.2.4, d.2.10, h.1.2
- 1. INTRODUCTION
- 2. THE APPLICATION
- 3. THE INTELLIGENT WORKSTATION
- 4. HOW THE APPLICATION SEES THE WORKSTATION
- 5. ISSUES
- 6. CONCLUSIONS
- REFERENCES
1. INTRODUCTION
A person interacts with a computing environment via a workstation. Computing environments are becoming more and more heterogeneous, with services provided by many organizations on a variety of platforms. Workstations are becoming increasingly powerful computing engines, and are becoming increasingly better adapted to communication with people.
The trend towards technically more capable workstations means that it is possible to build much more sophisticated user interfaces. As a consequence, the cost of developing a first class application is dominated almost completely by the cost of developing the interface. The trend towards provision of services on open networks makes this situation worse. Because the developer wants the service to have the widest possible market, the application may be exposed to a variety of capable workstations, so the developer must replicate many times the investment in user interface software. Comment
Most users have experience with the usual personal productivity software tools (wordprocessors, spreadsheets, graphics packages, etc.). These tools are typically used by people whose primary goal is not interaction with the computer, but who use the computer as a tool in performing their primary role. Compare a data-entry clerk, whose job it is to enter data into the computer, with a writer, who uses a word processor to write a book. For the former, differences in convenience of the interface mean that more or less data will be entered, with more or fewer errors. In addition, if the clerk's employer changes systems, the clerk will willingly undergo training. In the case of the writer, if the interface is not convenient, the system will not be used at all. Further, the writer sees training in the use of the computer as a distraction from his/her main work. For these people, the skills gained in the use of their productivity tools are of great value, and there is strong resistance to change which does not give immediate large benefits.
The fact that by far the largest market for network-based services is people of the second kind increases the developer's burden further, since the users demand the same kind of convenience and flexibility from the network-provided services as they are accustomed to from their personal productivity tools. Furthermore, the human makes use of a variety of services. Even if each of the services is provided with a high-quality interface, they will be all different and the human must learn to operate each one. Even worse, several services might share a similar function, such as editing text. It can be frustrating to use several different text editors, all to do things which the user's favourite word processor does more conveniently. In addition, the human may wish to integrate the product of several services into a single application using a variety of personal productivity tools.
The problem can only get worse in the future, since as the networks get wider, they permit access to the service by people from a wide variety of languages and cultures; and since additional technology such as voice interaction with continuous speech will multiply further the variety of workstations which much be served, as well as the quality demanded.
This paper argues that the application must not attempt to directly control the display and input interaction with the user. A workstation needs the capability to present a uniform interface to its user, adapted to that person's special needs. The workstation must be controlled by a user interface management system (UIMS), which includes the suite of personal productivity software required by the human. The application must view the interface as something like a database manager, presenting it with data and constraints but leaving the visualization and detailed interaction to the UIMS as instructed by the user. This requires development of a series of difficult abstractions of the services required by an application of the interface, and the refinement of these abstractions into standards, which would become part of the OSI Open Distributed Processing (ODP) standard. (The CCITT has a comparable standards process called Distributed Application Framework, or DAF.) comment
In the remainder of the paper, we first describe some precursor applications, then in more detail the workstation and its software. Following is a discussion of some of the abstractions required. A conclusion section completes the paper.
2. THE APPLICATION
The intelligent workstation will be an outgrowth of the personal computer with which we are familiar. We therefore have a partial view of how the workstation would look to the user. How the workstation and its user interface software will interact with network- based applications has been explored very little, however, so is much more difficult to visualize.
There are a number of examples of applications which are distributed between a mainframe and a personal workstation. For example, in the securities industry, there are database systems such as Pont Advantage developed by Pont Data in Sydney, Australia, which permit a securities analyst or trader to examine the price history of a particular stock in relation to other stocks in its industry, or a particular industry in relation to other industries or the market as a whole. The database is held on a mainframe. The user transmits a request to the database, which loads the selected data sets into a spreadsheet on a PC. The user can then view the data in many ways, using the spreadsheet and associated graphics package, independently of the mainframe.
This example, albeit technically sophisticated, is only partially an example of the solution of the technical problems described in this paper, since although it is distributed, it is not in an open environment. The PC and its software are provided by the supplier, so that the hardware and software environment are under the control of a single organization. This has allowed a very specific solution to be developed. Although these systems tend to be developed in an ad hoc way, careful study of such specific solutions will be essential to the correct formulation of the abstractions required for the development of open standards.
A more open environment is provided by videotex systems, which have been installed in a number of countries starting with the UK, and which have been commercially successful in some cases, particularly in France and in Australia. One can consider videotex as a precursor of the ODP environment. Although originally developed mainly as a passive database with quite limited update facilities, running on a mainframe with extremely limited capability terminals, it can be used to deliver a more active service.
The author was associated with a project centred on the Australian CSIRO (the major Australian research and development organization). Called SIRAGCROP, the project aimed to provide broadacre irrigation farmers in a major irrigated farming region with agronomic advice. The applications were a number of expert systems running on a DEC VAX/VMS environment, which communicated with the Australian Telecom's Viatel videotex service through gateway software running on the VAX. (The project, although technically successful, was ultimately abandoned due to disagreement among the several agronomic advisory and research organizations involved in it.) This example has the service provider and the interface provider separate organizations communicating with defined standards.
Another application, also developed by CSIRO, is a decision support system called SIRATAC which advises cotton growers on pesticide use. It runs on a DEC VAX/VMS cluster, communicating with the farmer/users via telephone lines. The application was first put into commercial use in 1981 and by 1986 was used in the management of about 25% of the Australian cotton crop (Hearn, et. al., 1986). Many of the farmers use personal computers as workstations, but only as emulators of terminals such as the DEC VT-100.
In 1986, CSIRO decided to re-engineer the system, in a major effort involving upwards of 10 man-years. The new system, called SIRATAC PLUS (Colomb, et. al 1988) was first built as a VMS application using tools like VMS/RALLY on the same platform as the original SIRATAC. As the system neared field trials, the users, most of whom by this time were using personal computers of one sort or another, felt that the dumb terminal interface was insufficient for a project described as "taking the service into a new decade". CSIRO decided to adapt the system so that growers with either Macintosh™ or IBM-compatible workstations with a certain minimum capacity would have the data entry and reporting modules on their workstations, leaving the database and processing functions on the VAX.
The Macintosh™ portion of this system was built, but as it reached the system test stage, the project was abandoned, partly due to technical problems and partly due to the collapse of the commercial organization which retailed SIRATAC to the farming community. The technical problems, related in Irrgang et. al (1990), manifested themselves largely in instability of the system and slowness of response. They were mainly due to lack of suitable operating system and communications products. One would expect that ODP standards would ultimately lead to software which would be a suitable substrate for implementing such systems. The experience with SIRATAC has clarified some of the concepts required for these standards.
Finally, in the late 1980's it began to be realized by some in the scientific management of CSIRO that there were a large number of decision support systems for agriculture being developed, by various CSIRO Divisions (which are quite autonomous), by the state Departments of Agriculture and by the large agri-industrial firms. One could imagine that a particular farmer might profitably consult perhaps ten different such systems. If they all had their own preferred platforms and their own independent user interfaces, it was felt that the resulting confusion would limit the uptake of the technology. It was proposed that a group be set up in CSIRO to develop standards for user interface and for the semantics of the data models, and to develop or acquire tools which would simultaneously implement those standards and reduce the cost to the research organizations of developing product. (Since the various organizations are more or less autonomous, it was felt that unless there were a cost reduction incentive, there would be little acceptance of the standards.)
This proposal was called AUSFARM, and ultimately failed to gain sufficient support to be implemented. However, as with SIRAGCROP and SIRATAC PLUS, the experience gained has resulted in significant insight into the open distributed computing problem, and is the basis for the ideas in the remainder of this paper. One of the most important lessons is that development of heterogeneous distributed environment requires a great deal of cooperation among autonomous organizations. If there were ODP standards and products, it would be much easier to bring up a cooperative computing environment piecemeal, therefore significantly reducing the cooperation required at the earlier stages when the vision lacks concrete detail and the payoff is distant.
3. THE INTELLIGENT WORKSTATION
The key architectural concept in this paper is the separation of the service applications on the network from the user interface running on the user's workstation. Workstations may be classified along two main dimensions: computing power and interface technology. There is a wide variety of interface technologies, including most commonly
- keyboard,
- character-oriented visual display unit, with limited graphics,
- bit-raster monitors in monochrome or colour, with a screen size ranging from 200 cm to 500 cm and a large range of pixel sizes,
- mouse-pointing devices with from 1 to 4 buttons,
- printers of many different types;
sometimes
- plotters,
- touch screens,
- braille,
- hand-printed characters,
- single-word voice commands;
and in the future
- multimedia workstations
- glove-style manipulators,
- continuous speech input and output,
- holographic three-dimensional displays.
Each of these technologies places different constraints on the interaction with the user, which a high quality interface must take into account.
Besides the different technologies, there is a wide range of differences among the humans using them, including
- language,
- cultural norms,
- personal preferences,
- organizational demands,
- sensory and motor handicaps, ranging from mild, such as colour-blindness or far-sightedness, to severe, such as blindness or paralysis.
The workstation has a number of standard data sets, including at present
- spelling dictionary,
- thesaurus;
and in the future
- dictionary of definitions, such as the NEXT has at present;
- dictionary of pronunciations;
- concept map, which stores the important terms in a domain together with their structural relationships. Concept maps are an outgrowth from the hierarchical thesaurus commonly used in information retrieval applications (Salton 1989), and are typically implemented as conceptual graphs (Sowa 1984). Concept maps would be necessary for the computer-based management of the literature in a particular technical subfield, and will become available in the near future. Some work along these lines is described by Colomb et al. (1991).
- multilingual term banks, which store important terms in a domain in multiple languages;
- case grammars, which are dictionaries augmented with semantic content used for natural language understanding and translation;
- common-sense knowledge bases, such as CYC (Guha and Lenat 1990).
Finally, the workstation comes equipped with a variety of personal productivity software, including
- word processor,
- spreadsheet,
- database,
- drawing package,
- computer-aided design package,
- display graphics manager,
- information retrieval database,
- hypertext system;
and in the future will have additional software, such as
- dialog manager, which controls conversations with the human,
- deductive database or knowledge base manager, which allows knowledge to be stored and used,
- text cruncher, which allows the extensive analysis of natural language text for the production of indexes, elicitation of rhetorical structure, and management of content,
- history manager, which remembers the history of the interaction of the workstation with the user, and is able to adapt the interface to the needs of the user in a semi-automatic way,
- service navigator, which will assist the user in identifying providers of required services on the network, and will also manage the documentation of those services,
- a range of interface managers, from low-level toolkits such as X11, through interface builders such as Serpent (Bass, et. al 1988) and UofA UIMS (Singh and Green 1991), to high level software which will manage the entire workstation and the suite of personal productivity tools in the interaction with the applications on the network.
The intelligent workstation will appear to the user as a unified tool for accessing computing services, which will take over the most interactive aspects of the interface from the application services. For example, we have noted above that some people use spreadsheets and their associated graphics packages to receive and manipulate the result of a statistical database search. One of the engineering Divisions of CSIRO used a spreadsheet to collect and check constraints on the input to a linear programming application. We can expect this trend in the use of personal productivity tools to accelerate, since the user gains by being able to do similar things in the same way, thereby conserving his/her skill base; and the developer gains a very sophisticated way to deliver a service at a low cost.
In particular, one would expect that the knowledge base manager would be a vehicle for access to the documentation of an application. It is becoming common to develop applications using Computer-Aided Software Engineering (CASE) tools, so that their specifications and design are available in a more-or-less formal system held in computer-readable form. It is common for this documentation to be held as a relational database. The database is called a data dictionary, and more recently a repository. This technology can be used to describe not only the data structures of an information system but also much of the computation provided by information systems (Debenham 1989, Lindley 1990).
In addition to the documentation for the specific application, the common sense knowledge base, a case grammar for the user's natural language and standard concept map of the general domain would be available on the workstation. One could also expect a concept map of the specific application and a hypertext documentation set to be provided by the application.
The knowledge-base manager would assist the user in making queries on the application's documentation, perhaps using the standard data sets. These standard data sets would act as deep context for the application-specific documentation. When the user reached the boundary of the information supplied by the application, the knowledge-base manager would turn to the standard data sets in much the same way as one might turn to a textbook in linear programming if unable to understand the documentation for a specific linear programming package.
In fact, we might find that these standard data sets, together with multilingual term banks and natural language text generators, would become a sort of pidgin for documentation of services available to speakers of many languages. The original documentation would be based in a highly structured form of particular natural language. The multilingual technical term banks could map the base concepts from the developer's language to the user's language, while the structure would come across unchanged. The structured documentation, now in the user's language, could be input to a natural language text generator also in the user's language and turned into readable text. The quality would be less than if it were produced by highly-trained native speakers, but it might be adequate. It might even be better than much present native-language documentation. In any case, it would permit very wide access to a network based service at a reasonable service-specific capital cost. comment
4. HOW THE APPLICATION SEES THE WORKSTATION
The application will see the user through the tools running on the workstation. The interface will therefore have to be formulated in terms of the "reverse" side of the workstation, which is an unfamiliar view. The situation is illustrated in Figure 1.
The application and the workstation will first negotiate an agreed set of capabilities and interface standards which are sufficient to present the service to the workstation. It is possible at this stage that connection will be denied on the grounds that the workstation has insufficient capability or that no common standard exists for transmission of complex data types.
Assuming a connection is established, the application will control the dialog between the user and the interface remotely, by telling the workstation what menus to display, which options in a menu are currently available, and providing the specifications and constraints for the spreadsheets, text documents, graphics displays and other such objects.
Finally, the routine interaction will allow the application to get commands, parameters and data from the interface, and to present data to the interface. The user will use the workstation's productivity tools to accept commands and to manipulate data, possibly for re-transmission to the application.
As well, the application has a number of what might be termed "meta-services". It must present its documentation, including explanations and tutorials, through the tools in the workstation. In addition, it needs to advertise its services in a standard network application such as X500 or the ODP Trader, which functions like the telephone Yellow Pages, assisting potential users to find the services they require.
There are two aspects to the problem:
- definition of the characteristics of the workstation tools;
- definition of the data structures to be passed back and forth.
The characteristics of the tools are specification of the internal data structures and methods, while the data structures passed back and forth are messages. The terms method and message are derived from the object-oriented programming world.
4.1 Methods
The database tool is perhaps the easiest to conceptualize. The necessary standard exists in large part. SQL data description (DDL) and manipulation (DML) languages contain most of the features needed, and could be a model for other tools. comment
Now consider the spreadsheet tool. The main data structure is a two-dimensional array of fields, each of which is of a small number of elementary types (e.g. numeric, text), but associated with each is a number of format descriptors (number of decimals, right/left/centre adjustment, etc.). Also associated with each cell may be a computation rule expressed in a suitable language. In addition, there are some global parameters, such as the number of rows and the number of columns. Finally, there may be some characteristics which we wish to allow the user to change, and some which must be maintained.
We therefore need a standard type generator, together with standard format, computation and constraint languages. These would reflect the data structures used in recovery of a stored spreadsheet, so that in a sense, they already exist. The difference is that they must be part of the contract the spreadsheet maintains with the network, so must be formally defined, well documented, and adhered to by all relevant parties.
A similar standard will be needed for word processors, graphics packages, databases, and the tools to be developed. comment
Besides standards for individual tools, we will need standards for their interactions. For example, an output spreadsheet might have a number of graphics views which are usual. An accounting package might have several dozen usual reports and graphics (its competitive edge would likely be these reports, since the computations performed are standardized). It will be necessary for the application to be able to specify not only a data structure to receive the output, but also the connections between the tool used as a primary repository and the tools used for secondary services.
Standard specifications for these methods must be unambiguous and complete. For this reason, it is common to use formal specification languages, which themselves may be standard. For example, the syntax of programming languages are usually specified in Backus-Naur Form, while telecommunications protocol standards are published in languages such as SDI (CCITT 1984), LOTOS (ISO 1987a) or ESTELLE (ISO 1986a). Formal specification languages for complex procedures are being developed, including Z, VDM and Object-Z (Duke et al. 1991), and some object-oriented languages such as Eiffel (Meyer 1988) may have sufficient formal properties to be candidates for standard specification languages.
4.2 Messages
Messages require a type constructor language comparable to that used to define the data structures for the methods. The problem is comparable to the definition of complex data types for object-oriented data stores and for the closely related persistent programming languages. An example of the latter is Napier (Atkinson and Morrison 1987, Morrison et. al 1989), which is built on the type language described by Cardelli and Wegner (1985).
Besides these types, composed as complex structures from simple elementary types, we must consider types such as the document. A standards process exists for the structure of documents (Office Document Architecture or ODA, ISO 1987b) and for their appearance (Standard Generalized Markup Language, or SGML, ISO 1986b). A related type is Hypertext, for which a standards process exists (e.g. Moline et. al 1990). It appears that hypertext standards will emerge as developments from ODA and SGML. These types will be important not only for the transmission of documentation and tutorials, but also for reports: for example a balance sheet could be prepared by a general ledger package as a table of numbers annotated in SGML. comment
Another important type is the graphic object. There are a number of drawing, drafting and computer-aided design productivity tools available which can create and manipulate these objects. There are also many applications for which it is convenient to represent aspects of their data structures as graphics objects. Examples are project planning (the task network), concept maps (the map is conveniently represented as a semantic net), and CASE tools (entity-relationship diagrams, dataflow diagrams). At present, these applications tend to have their own graphic object manipulation systems. It would be more convenient to be able to use the drawing or computer-aided design tools already available on the workstation.
Multimedia types are presently being actively investigated. These types include high-resolution images, high-resolution sound, and motion pictures. Issues of concern include data compression and synchronization, for example between the image and sound in a motion picture type, particularly when both are compressed.
A difficulty is that the applications frequently have constraints on the graphic structures which are global in nature, and which must be dynamically maintained. An example is a planning network, where the connections between events must be maintained when the icon for a particular event is moved on the display, which may require re-drawing a number of connections. Also, the network may be so constrained that icons for earlier events must appear to the left of icons for later events. Drawing packages tend to treat each object as separate, although computer-aided design packages have a more global view. We have here an example of a situation where a great deal of thought must go into the separation of function between the productivity tool and the service application.
Other types, such as the production rule and the related concept map not presently much used in interchange, will also require standard languages.
4.3 Constraints
It will be necessary in many cases that the data structures visible to the user or passed between the interface and the application be subject to constraints of one sort or another, which will require standard ways of specifying constraints. Extensions such as triggers have been proposed to SQL (Date 1983), which may be a good base to work from. More generally, first order logic, probably with aggregation functions (Klug 1982) is a good candidate for this purpose. It will be necessary for the constraints to be intimately integrated with the type constructor languages, since the structure of the constraints will commonly mirror the structure of complex data objects.
5. ISSUES
The discussion so far has implicitly assumed that the application views the interface as something like a database manager. While in large part this is a valid assumption, there are at least two major differences between the interface and a database.
First, the database is static. Data stored is assumed to return unchanged. The whole purpose of the interface may be to get the user to make changes to the data presented. It may be necessary for the interface to be able to return to the application a trace of changes to the data structures shared between the user and the application, in much the same way as the transaction logs database systems maintain for system failure recovery or user tools employ to support undo commands.
Second, the database is passive. It performs only when asked to do so by the application. In the present situation, the user is in charge, so that the orderly exchange of commands and responses may be disturbed by interrupts, requests for status of processing, and the opening of additional windows. It will therefore be necessary to have a control language over and above the language for the transmission of data. This may be as simple as that the application must be prepared to receive unscheduled messages and act appropriately on them.
As a consequence partly of the active nature of the interface and partly of the distributed nature of the system, it will be necessary for the application and the interface to maintain synchronization. In particular, the interface must be kept informed of the messages the application is prepared to receive in any state, much as pull-down menus customarily highlight commands which are relevant in the current situation. This will require synchronization between finite-state automata, which is a feature of many layers in the communications standards, and will have aspects pertinent to ODP systems such as are considered in this work.
Tying together the application and the workstation will be a network access manager running on the workstation and a workstation access manager running as a part of the service. When the user attempts to connect to a service, it will first be necessary for the service to establish whether the workstation has sufficient methods to support the application, and also whether it can support the languages and protocols available to the workstation. If there is a history manager on the workstation, the application might be able to get an indication of the user's level of knowledge of the various productivity tools available. Based on this information, the application can determine whether the workstation is qualified to access its service and, if so, set up the appropriate communication protocols. There might be several levels of service, each requiring more capability on the part of the workstation software, or perhaps a higher level of service might require a high degree of competence on the part of the user in some of the workstation software. Once the connection is established, these access managers will mediate the interchange between the application and the workstation tools.
An important set of tradeoffs, particularly in the early stages of development of the network of applications, will be between the availablilty of productivity tools and the adequacy of those tools for particular applications. Some of the first examples will inevitably be crude.
6. CONCLUSIONS
This paper is based on the thesis that the future pattern of computing will be services available on wide networks to users who have powerful workstations with a great deal of personal productivity software. It has examined some of the expected capabilities of workstations in the next decade. Its main focus has been on the problem of constructing applications which communicate with their users indirectly, via the personal productivity tools, and it has sketched some possible solutions.
It remains to consider how we get there from here. Both sides of the system must evolve: the personal productivity tools to have open "reverse sides", while the applications must be developed to use these tools. Since the tools and the applications are generally constructed by distinct organizations, it is in neither party's commercial interest to move until the other has.
One possible way forward is to make use of newly emerging facilities to allow personal productivity tools to send commands to each other, as well as to interchange data. Such facilities are available, for example, in the Macintosh™ System 7. In order for these facilities to be useful, it will be necessary for productivity tool developers to publish their command and data structure formats. It would be possible to write a workstation manager which would mediate between network applications and productivity tools using these facilities. The application developer would have to cope with a number of different formats, but could limit investment by starting with a very small number of the most common packages, then gradually expanding. As the practice became more common, the tool developers might modify their products to make the job easier, and the synergistic process might take off from there.
REFERENCES
ATKINSON, M. and MORRISON, R. (1987) "Polymorphic names, types, constancy and magic in a type secure persistent object store" Proceedings of the Persistent Object Systems: Their design, Implementation and Use Papers for the Appin workshop, 1987, August, University of Glasgow, University of St. Andrews pp. 1-12.
BASS, L., HARDY, E., LITTLE, R and SEACORD, R. (1988) The Serpent User Interface Management System Report CMU/SEI-88-TR-5, Software Engineering Institute, Carnegie Mellon University, USA.
CARDELLI, L. and WEGNER, P. (1985) "On Understanding Types, Data Abstraction and Polymorphism" ACM Computing Surveys Vol 17, No. 4, pp. 471-523.
CCITT (1984) Functional Specification and Description Language (SDL) CCITT Red Book Volume VI. Fascicle VI.10 Recommendations Z.100-Z.104 VIIIth Plenary Assembly, 8-19 October, 1984.
COLOMB, R., HEARN, B., BROOK, K., JANSEN, R., ASHBURNER, N. and CLARKE, M. (1988) SIRATAC: Expert Decision Support for Cotton Pest Management Technical Report TR-FD-88-01 CSIRO Division of Information Technology, Sydney, Australia.
COLOMB, R.M., ROBERTSON, J. and JANSEN, R. (1991) "The CSIRO Hypertext Research Project" Australian Database and Information Systems Conference University of New South Wales, Australia.
DATE, C. J. (1983) An Introduction to Database Systems, volume II Addison-Wesley.
DEBENHAM, J. K. (1989) Knowledge Systems Design Prentice-Hall.
DUKE, R., KING, P., ROSE, G. and SMITH, G. (1991) The Object-Z Specification Language, Version 1 Technical Report 91-1, Software Verification Research Centre, University of Queensland.
GUHA, R.V. and LENAT, D.B. (1990) "Cyc: a Midterm Report" AI Magazine Vol 11, No. 3, pp 32-59.
HEARN, B., BROOK, K., ASHBURNER, N. and COLOMB, R. (1986) "SIRATAC, A Cotton Crop Management Expert System" First Australian Artificial Intelligence Congress, Melbourne, November.
IRRGANG, R., MCGOWAN, C. and STAFFORD, B. (1990) "Architecture of a Distributed Decision Support System" Australian Software Engineering Conference, May.
ISO (1986a) ESTELLE DP 9074, ISO/TC 97/SC 21 N1575, International Standards Organization, October, 1986.
ISO (1986b) Standard Generalized Markup Language DIS 8879 International Standards Organization
ISO (1987a) LOTOS DP 8807, ISO.TC P9/SC 21 N2152, International Standards Organization, August, 1987.
ISO (1987b) Office Document Architecture DIS 8613 International Standards Organization
KLUG, A. (1982) "Equivalence of Relational Algebra and Relational Calculus Query Languages Having Aggregate Functions" Journal of the ACM, Vol. 29, No. 2, pp 699-717.
LINDLEY, C.A. (1990) "An Integrated Conceptual Model for Data, Information, and Knowledge" Thirteenth Australian Computer Science Conference, Australian Computer Science Communications, Vol 12, No 1, pp. 226-235.
MEYER, B. (1988) Object-oriented Software Construction Prentice-Hall.
MOLINE, J., BENIGNI and BARONAS, J. (1990) (eds.) Proceedings of the Hypertext Standardization Workshop January 16-18, Special Publication 500-178 National Institute of Standards and Technology, USA.
MORRISON, R., BROWN, A., CARRICK, R., CONNOR, R., DEARLE, A. and ATKINSON, M. (1989) The Napier Type System" Proceedings of the Persistent Object Systems: Their design, Implementation and Use Newcastle, NSW Springer-Verlag pp. 253-270.
SALTON, G. (1989). Automatic Text Processing. Addison-Wesley, Reading, Massachusetts.
SINGH, G. and GREEN, M. (1991) "Automating the Lexical and Syntactic Design of Graphical User Interfaces: the UofA UIMS" ACM Transactions on Graphics Vol. 10 No. 3, pp 213-254.
SOWA, J.F. (1984) Conceptual Structures: Information Processing in Mind and Machine Addison Wesley.
Annotations February, 1999
1.1 This trend was interrupted by the introduction of the World-Wide Web. The Web removed the responsibility for provision of workstation user interface software from the information service provider to the user. The user provides a web browser and the service provider uses a standard communication protocol and markup language to implement the interface. This has permitted universal access to services at the cost of interface quality and rigidity. Even in 1999 Web-based interfaces are awful compared to platform-specific interfaces. The wide availability of speech recognition software, and the wide variety of mobile information appliances, together with more flexible markup languages like dynamic HTML and XML, will bring the problem discussed in this paragraph back to the fore.
1.2 The Web has brought with it new standards bodies, notably the W3C, which is responsible for HTTP, HTML and XML. The Z39.50 standard is also becoming more prominent.
2. This section is largely superseded by Web applications supported by the Web browser with plug-ins, implementing the Web protocols. No longer news as such.
3. Workstation operating system features like OLE, Active X and OpenDoc make it possible to integrate standard packages as components more-or-less at will. Some of the personal productivity tools, notably Microsoft Word, can be used as plug-ins for Web browsers. However, the lack of standards for the complex data structures involved has prevented much development along these lines. Some standards exist, such as Acrobat and ShockWave, with easily downloaded plugins available for free, but these products have not taken hold as native workstation productivity tools. There is still an enormous amount of work needed before the vision of this section could be reality. For example, will people develop standard Word style sheets corresponding to standardised XML DTDs?
4.1.1 Some advances have been made on use of SQL databases as abstract data types. Pre-web attempts were reported by Colomb and Chongviliawan (1992); Colomb (1993, 1994). The main research in this area has been the extension of the information retrieval protocol Z39.50 to incorporate SQL (Zinc project). However, the most critical problem is not schemas, but semantics - agreeing on what the words mean. This issue is canvassed in Colomb (1997).
4.1.2 For example, an abstract data type has been developed for persistent graphs, based on the relational database ADT (Colomb and Eilertsen, 1997).
4.2 There has been considerable development in complex message types, particularly in electronic data interchange (EDI). The recent introduction of XML promises to make EDI much more accessible. See for example Wing et al. (1998). However, very much work remains to realise the vision of this section.