-
Notifications
You must be signed in to change notification settings - Fork 0
Terms
This document describes how certain words are used throughout the rest of the documentation. Some of these words are domain-specific, and so they are defined here. Others are common words that are intended to be used consistently according to a limited and precise interpretation.
A parameter is a named set of possible values of a given type. In other words, parameters are referred to by name and can usually take on many different values.
A range is the general term for a restriction of a numeric parameter. Ranges may be specified in various ways, but the result is called a range in this document.
A limit is one of the endpoints that define a range. For example, a value that has been assigned to inclMin is a limit. A limit is thus the concrete counterpart to the abstract idea of a range.
An interval is another way to specify a range, in addition to limits. Intervals are not officially supported, but the concept is useful. When convenient, intervals will be used to express ranges more compactly. They act as a shorthand that replaces limits. Intervals will use the standard mathematical notation using square brackets. The interval [1,5[ would then be translated to inclMin = 1, exclMax = 5. In addition, a missing limit is indicated by an asterisk. The interval ]*,5] would thus be translated to inclMax = 5.
A multi-range is a value restriction that consists of multiple ranges. A parameter that is defined to be in [1,5] or [4,7] would have been defined using a multi-range.
A situation is allowed if and only if it does not prevent InPUT from running. Legal is synonymous with allowed. A "situation" is some state of the world, and the features that are relevant in this context include the details of a configuration and/or sequence of calls to the API. An illegal situation will therefore prevent InPUT from running.
A situation is valid if and only if it leads to the expected outcome. This is in contrast to the notion of legal or allowed situations. An invalid literal, for example, may be allowed, yet InPUT may simply ignore it.
A parameter is dependent on another parameter if it cannot be initialized unless that other parameter has already been initialized. A parameter may depend on the value of another numeric parameter because it was defined relative to it. It can also be a structured parameter that depends on a nested parameter.
In this document, an accessor is a method for accessing the object field corresponding to a parameter nested inside a structured parameter. Traditionally, an accessor returns a value and a mutator modifies a value. When a distinction is important, those mechanisms are instead called getters and setters.
A null value is a special value that represents "no value", or an
"invalid" value. Depending on the implementation language, this may
be null or nil or None, etc.
A parameter ID is supported if it is included in the set of IDs that are supported by a design space or design (depending on context). This definition is potentially confusing, which makes it particularly important to include here. An ID may be valid in the sense that it can be used to generate, get, or set values, yet it may not be supported. An ID may also be valid or supported in different circumstances. This confusion is an unfortunate side-effect of the fact that designs and design spaces do not always agree on which IDs are supported, as well as the fact that extending a design so that new parameters can be accessed through it does not cause its reported set of supported IDs to be updated.
Therefore, in an attempt to attain some measure of consistency, parameter IDs that can be meaningfully used in a given context are described as valid, using the usual definition. Using the word 'supported' to describe a parameter ID shall simply be avoided.