BS ISO/IEC 8824-3:1995 Information technology. Abstract syntax notation one (ASN.1) - Constraint specification
Withdrawn
Printed version of this is available at library. To request, please e-mail to referencepk@usm.my and include a copy of this record in your e-mail.
This Recommendation|International Standard is part of Abstract Syntax Notation One (ASN.1) and provides notation for specifying user-defined constraints and table constraints.
Application designers require a notation to define a structured data type to convey their semantics. This is provided in ITU‑T Rec. X.680|ISO/IEC 8824‑1 and ITU‑T Rec. X.681|ISO/IEC 8824‑2. A notation is also required to further constrain the values that can appear. Examples of such constraints are restricting the range of some component(s), or using a specified information object set to constrain an “ObjectClassFieldType” component, or using the “AtNotation” to specify a relation between components.
This Recommendation|International Standard provides the notation for the general case of constraint specification.
NOTE 1 For historical reasons the special case of a “subtype constraint” is specified in ITU‑T Rec. X.680|ISO/IEC 8824‑1. Constraint notation can appear (in parentheses) after any use of the syntactic construct “Type”, and the purpose of this Recommendation|International Standard is to specify the general case of what goes in the parentheses.
NOTE 2 Multiple constraints (each inside its own parentheses) can be applied to the same “Type”, as the result of constraining a “Type” is itself formally a “Type” construct.
When a constraint is applied to the textually outermost use of a “Type” construct, it results in the creation of a new type which is a subtype of the original (parent) type.
A subtype of a parent type can itself be used in defining other subtypes of the same parent type in other uses of the constraint notation. Thus the subset of values constituting a subtype can be defined either by limiting the range of the parent type, or by specifying the subtype as a union of sets of values.
NOTE 3 The “ValueSet” notation specified in ITU‑T Rec. X.680|ISO/IEC 8824‑1, subclause 13.5, provides a further means of specifying a subtype.
Constraints may also be used to produce a subtype of a parent type (as described above) when the notation is embedded within another type. However, some “component relation” constraints are textually included following a “Type” (within a set or sequence type definition), but are not used to restrict the set of possible values of the “Type” which they follow (the referencing component). Rather, they specify a relation between the value of the referencing component and the value of one or more other “Type”s in the same set or sequence type (called the referenced components).
Component relation constraints can be seen as subtyping the sequence type within which they are embedded, but not necessarily the referencing type.
A constraint on an “ObjectClassFieldType” component can be applied by restricting the type or values in the component by using an information object set. Such constraints are called table constraints, since they are specified in terms of the “associated table” of the object set. The component relation constraints defined in this Recommendation|International Standard are a special case of table constraints.
Finally, a “Type” may be subtyped by specifying the set of values in the subtype by human-readable text. Such a constraint is called a user-defined constraint. For example, a user-defined constraint can be specified to constrain a BIT STRING to the set of values produced by the encryption of a value of a specified ASN.1 type.
It is the purpose of this Recommendation|International Standard to provide the notation to be used for specifying table constraints (including component relation constraints), and user-defined constraints.
NOTE 4 In general, full support for the specification of constraints in a flexible way (particularly component relation constraints, subtyping constraints, and user-defined constraints with a formally defined body) would require notation with a power comparable to that of programming languages. Such power can only be sensibly provided by the establishment of links from the ASN.1 notation into some other defined computer language. This version of this Recommendation|International Standard does not provide such links, and hence supports only a small number of constraining mechanisms.
While the embedding of notation defining constraints (subtypes and relationships) will frequently be the most convenient form of specification (particularly for the simple subtyping of primitive components of structures), separate (external) specification will sometimes be preferred, particularly where the constraints are being imposed by a separate group from that which defined the basic protocol.
NOTE 5 The parameterization defined in ITU‑T Rec. X.683|ISO/IEC 8824‑4 is specifically designed to enable a piece of ASN.1 specification (and in particular, a constraint) to be parameterized, allowing the actual constraint to be imposed by some other group that provides actual parameters for the parameterized construct.
The notations for constraint specification supported here are:
— user-defined constraints (see clause 9);
— table constraints, including component relation constraints between two components which are carrying values related to an information object, defined using the notation of ITU‑T Rec. X.681|ISO/IEC 8824‑2 (see clause 10).
The application of table constraints to the “InstanceOfType” construct of ITU‑T Rec. X.681|ISO/IEC 8824‑2, Annex C, is specified in Annex A of this Recommendation|International Standard.
