-
Notifications
You must be signed in to change notification settings - Fork 0
Home
You may wish to start by reading about the [purpose of this project] Purpose and the definitions of some important terms that occur frequently in this document. An explanation of versions of the specification may also be of interest.
What follows should provide a brief overview of InPUT, this project, and enough relevant links to serve as a good jumping-off-point.
XML configuration files are used to define design spaces, designs, and code mapping configurations. A design space is made up of one or more parameter definitions. Designs are essentially name-value mappings and exist relative to a design space. When parameters have an arbitrary, user-defined type, design space configurations include a reference to another configuration that maps parameter IDs to type information that is appropriate to the particular implementation language.
Once the necessary configurations have been defined, an implementation of InPUT interprets the configurations and allows some suitable representation to be manipulated and operated on. The API supports operations such as generating values for parameter IDs using the corresponding definitions, creating designs from design spaces, and accessing the values of the various parameters in a design.
- Documentation
- Validation
- Test suite
- Testing tools
The test suite forms an executable specification against which new versions of InPUT4j can be directly validated. Non-Java implementations will first have to port the tests. Either way, the test suite can be used to validate compliance with the specification.
The test suite is enabled by a set of custom tools to simplify testing.
The specification can further be divided into two different aspects of InPUT: the configuration and the API. The configuration is already defined to some extent by the XML Schema. This specification deals with the remaining details. The API specification should describe the concepts and operations that are available in InPUT.
This includes details such as which strings are valid literals; how range limits interact, and how they can be specified; what a valid ID looks like; and, overall, how InPUT interprets various combinations of configuration elements.
This includes the concepts that InPUT deals with and the operations that are related to them. Object-oriented language is avoided as much as possible, as long as the discussion remains unhindered. Since the specification is essentially a reverse-engineering of InPUT4j, using OO language may sometimes be too convenient to resist.