Principal Developer, TertiaLink, Inc.

To offset IBM's withdrawal from the SOHO desktop marketplace with regards to OS/2, the OS/2 community must become self-sufficient with respect to an operating system that's vendor independent and more responsive to user needs.

1. Overview

   1. The following outline represents a work-in-process of a complete proposal of an organization, its staffing, and its means to provide an alternative and independent means of software users to have investment protection in terms of post-sales support and enhancements.  Though initially directly at providing such for OS/2 users through a fully compatible and extensible operating system tentatively dubbed "Warpicity", the means support all forms of software development.  Warpicity represents a generic model of an operating system intended to support the APIs and thus the applications available on Intel (and non-Intel) processors, specifically Linux and MS Windows-based OSes.
   2. The proposal uses the "classical waterfall" method of the software development process: specification, analysis, design, construction, and testing.  It uses a single interactive tool, the Developer's Assistant (DA), which provides the developer with all the necessary clerical assistance supporting a "true" integrated development environment (IDE), making the system the only source of documentation and thus the only source for system status as well.
   3. The Developer's Assistant as an application derives from using standard structured analysis and design methods on the software development process in the same way we would use them on any client process and for the same reasons: increased throughput, leading to reduced costs and higher productivity.  The analysis resulted in the proposed specification-centric (and -only) approach: no use of any programming language, only a specification language based on established logic programming methods.
   4. The specification language must lead to an "executable" in some "target" machine language.  We achieve this by incorporating the specification of each target machine architecture within our common specification pool or library.  We then use logic programming instead of programming logic to translate the components of any higher level specification in terms of those of a lowest level target machine architecture.
   5. This translation of any component follows the logic programming habit of providing "all" possible results.  Thus we can select from them those which give the best performance or those which minimize memory space.  We can also choose in any instance of a component occurring within another component to execute it inline or as a called subroutine.  This leads to achieving performance levels not possible with any programming language like C or C++ and at minimum equal to the best assemby language.
   6. The last question which remains lies in maintenance.  The specification-centric approach offers the lowest cost and the fastest means of performing maintenance than any programming-centric alternative, 
 including all forms of OO.  In fact it has the ability to respond to a change request in less than the average interval between requests.
2. Proposal
   1. Independent OS/2 user community
      1. Investment protection
         1 Unlimited scalability
            1. Platform independence
         2 Unlimited extensibility
            1. Function
      2. Vendor independence
         1 User determines post-sales support (who)
         2 Unaffected by vendor status
            1. Out of business
            2. Product withdrawal
            3. Support withdrawal
            4. Market segment
         3 Non-proprietary choice
            1. No copyright
            2. No intellectual property
            3. User owns "source code".
      3. Buyer independence
         1 "Full" product ownership
      4. Operating Systems
         1 Target system
            1. "Warpicity": The Essence of Warp
               1. A single "generic" operating system incorporating "all" the
                  functions and features of existing operating systems with
                  support for "all" applications (past, present, and future).
               2. Platform independent
         2 Source systems
            1. OS/2
            2. Windows 3.xx, Windows 9x, Windows NT
            3. UNIX, including LINUX, HP UX, Sun Solaris, IBM AIX, SCO UNIX
            4. IBM, including VM, MVS, VSE, and OS/400
   2. Presenter
      1. Lynn H. Maxson
         2 71233,1254 CompuServe
         3 OS2FORUM, S14/For What It's Worth
3. Organization
   1. Member-based
      1. Direct democracy
         1 One member, one vote
            1. Every vote counts
      2. Board as a whole
      3. Member "rights"
         1 Unlimited Usage
            1. No copy limits
         2 Unrestricted usage
            1. Including ability to compete
               1. Note: Allows any dissenting minority interest to pursue
                  alternate course, preventing tyranny of majority
         3 Full ownership
            1. Source
               1. Specification pool/library
            2. Tools
               1. Developer's Assistant (DA)
   2. Subscription-based
      1. Annual
      2. Minimal fee
         (suggested $20/yr)
4. Staffing
   1. Performance-based contract
      1. Permanent staff positions determined by "board"
   2. Chief Librarian
      1. Communication
         1 Internal/External
      2. Administration
         1 Fincance
   3. Chief Developer
      1. Responsible for all development
5. Means
   1. Specification-centric development
      1. Premise
         1 Hardware, software: 100% logic-based
      2. Recognises "specification" step as "central transform"
         1 Application of SAD to SDP
            1. Physician, heal thyself.
         2 Write specifications only: no writing of programs
            1. Prolog is a programming language.  Any use instance is capable
               of producing only a "single" program, i.e. incapable of
               producing an application system of any combination of batch,
               interactive, and distributed.
            2. Prolog uses the same "rule-based" approach to generating
               machine language executable code as do non-logic programming
               languages, each use instance of which also only capable of
               producing a single executable.
         3 Specification process
            1. Specification pool/library
               1. The set of "all" specifications.
            2. Development stages
               1. Specification
                  1. Formal translation of "requirements" into specifications
                     for addition to specification pool.
                     1 Includes machine architectures
               2. Analysis
                  1. Selection of an "(named) instance" set of specifications
                     from the specification pool.
                  2. Ambiguity resolution
               3. Design
                  1. Specification of "desired" forms: hierarchical setting
                     of subassemblies: the "design" specification
               4. Construction
                  1. The translation of a specification from "analytical
                     (logical)" to "executable (physical)" format.
               5. Test
                  1. As the specification must be "logically correct" only an
                     error in the "external" requirements can occur.  This
                     results in "adding" a "new" requirement, resulting in
                     turn in a "new" specification.  No "modification" of an
                     "existing" specification occurs.  Thus only a new
                     "version" with corresponding "replacements" occurs: no
                     rewrite (copy with replacements)
            3. Advantages
               1. Respond to change requests faster than they arrive:
                  response time < change rate interval
         4 Specification
            1. Inherently reusable
            2. Intrinsic patterns
            3. Note: Requires no "outside" (user) intervention
      3. Supports integrated development of application systems
         1 <application system> ::== <application>...
         2 All options/combinations
            1. Batch
            2. Interactive
            3. Distributed
               1. Peer-Peer
               2. Client-Server
         3 Unlimited scalability
            1. Number of applications per system
            2. Size of application
         4 Eliminates need for "freezing"
      4. Provides "true" Integrated Development Environment (IDE)
         1 Only the system can provide its status: completely internal, no
            external components
            1. Eliminates "need" for "status meetings": no one knows more
               than what system can provide
         2 Has never occurred previously in history
         3 Uses only a "single" tool: Developer's Assistant
            1. Connects requirements to specifications
            2. Supports all operations on specifications
            3. Translates a specification into an executable
      5. IPO format
         1 Input...........Process.........Output
         2 <requirement>   [specification] <specification>
         3 <specification> [analysis]      <specification>
         4 <specification> [design]        <specification>
         5 <specification> [construction]  <executable>*
         6 <executable>*   [testing]       <requirement>
         7 Note: <executable>* ::== <executable specification>
         8 Note: Flawless "internal" logic within stepwise refinement of
            specification.  Thus no internal logic errors: produces logically
            consistent specification.  Only "external" errors possible:
            requirement.  Correction: add new requirement, repeating process.
      6. <specification><op><specification> -> <specification>
         1 Conforms to set theory as implemented in relational database
            managers: <set> <op> <set> -> <set>
      7. <requirement> -> <specification> -> <executable>* -> <requirement>
         1 <executable>* ::== <executable specification>
      8. "Universal" Modelling Language (UML)
         1 As opposed to OO "Unified"
      9. Level of Abstraction
         1 Manufacturing levels
            1. Final Assembly: Highest (relative to this construction) Level
               of Abstraction
               1. Bill of Material
                  1. Provides stepwise refinement through all lower levels in
                     which all subassemblies resolve into the raw materials
            2. Sub-assembly
               1. <sub-assembly> ::== <raw material>...|
                  [<raw material>][<sub-assembly>]
            3. Raw Material
               1. Machine Archectecture
            4. Low-level code (LLC)
         2 Predicate levels
            1. Zero level predicate
               1. Machine architecture (RISC)
            2. First level predicate
               1. Machine architecture (CISC)
            3. Second level predicate
               1. Control structures
                  1. Sequence
                  2. Decision
                  3. Iteration (recursion)
            4. Third level predicate
               1. First level function (atomic)
            5. Fourth and higher
               1. Higher-level functions (non-atomic)
            6. Low-level code (LLC)
               1. Exception: recursion
   2. Current thinking
      1. Specification language based on predicate logic
         1 Predicate
            1. Name
            2. Head
               1. Variables
            3. Body
               1. Assertions on variables
                  1. Including "control logic"
            4. Sample: Taken from Trilogy User's Guide
      2. Language choices
         1 PL/I data types
         2 APL2
            1. Operators
            2. Symbol Set
            3. Strict left to right/right to left evaluation
               1. No operator precedence
               2. Force use of parenthesis
         3 Predicate logic
      3. References
         1 Logic Programming
            1. Visual Prolog--Causal Logic
            2. "Simple Logical: Intelligent Reasoning by Example"--Flach
               1. Language specification
                  1. Syntax
                  2. Semantics
                  3. Proof-theory
                     1 Note "proof" difference between logic programming
                        (Prolog and Trilogy) and programming logic (C, C++,
                        JAVA, COBOL, PL/I, etc.).
                  4. Meta-theory
                     1 Note: If capable of expression within the same
                        language, it becomes "self-reflexive", "closed
                        (logically complete in terms of necessary and
                        sufficient), and "extensible" (unlimited).
            3. Trilogy--Predicate Logic
            4. Trilogy User Guide--Paul Voda
            5. "Programs for Fast, Flawless Logical Reasoning"--Wos
               (CACM,June 1998)
         2 Set Theory
            1. "Sets, Relations, Functions: An Introduction"--Selby, Sweet
         3 Functional Programming
            1. "Functional Programming: Application and Implementation"--
            2. "Principles of Functional Programming"--Glaser, Hanikin, Till
            3. "Recursive Programming Techniques"--Burge
         4 Z-specification Language
            1. Predicate logic
            2. "Software Development with Z"--Wordsworth
            3. "Z in Practice"--Barden, Stepney, Cooper
            4. "Z: An Introduction to Formal Methods"--Diller
            5. "Using Z: Specification, Refinement, and Proof"--Woodcock,
         5 Artificial Intelligence
            1. Purpose
               1. Pattern recognition/mapping
               2. Experiential system: Developer's Assistant
            2. "Artificial Intelligence: A New Synthesis"--Nilsson
            3. "Fundamentals of the New Artificial Intelligence"--Munakata
         6 Lambda calculus
            1. "Machine Organization,..."--Wegner
   3. Universal Name Directory (UND)
      1. Relational Form
         1 EGA_TABLE
            1. PRIMARY_NAME
            2. PRIMARY_INDEX /* homonym and version control */
            3. PRIMARY_TYPE
               'E' -- element name
               'G' -- group name
               'A' -- alias name
         2 ALIAS_TABLE (Synonym)
            1. ALIAS_NAME
            2. ALIAS_INDEX
            3. PRIMARY_NAME
            4. PRIMARY_INDEX
         3 GROUP_TABLE
            1. GROUP_NAME
            2. GROUP_INDEX
            3. RELATIVE_POSITION
            4. REFERENCE_NAME
            5. REFERENCE_INDEX
         4 FROM_TO_TABLE
            1. GROUP_NAME
            2. GROUP_INDEX
            3. FROM_REL_POSITION
            4. TO_REL_POSITION
   4. AD/CYCLE
      1. Software Development Cycle (SDP)
         1 specification|analysis|design|construction|test
      2. Product
         1 Currently
            1. Bachmann
            2. CASE tools
            3. Compilers
            4. Editors
            5. ICE (Integrated Construction Environment): not IDE
         2 Proposed
            1. Developer's Assistant
      3. Data Respository
         1 UND-based