|
|
|
The SET type allows the definition of a fixed number of components where order is irrelevant. Within the set each component must be given a name, unless its base type is CHOICE. When a set is transferred from one system to another the items in the SET can be sent in any order. Items in the set can be optional, as indicated by the OPTIONAL keyword, for example:
Contact ::= SET {
name [1] GraphicString,
title [2] GeneralString,
businessNumber [3] NumericString,
afterHoursNumber [4] NumericString OPTIONAL}
When referring to SET items in NCL they are referenced by name, and hence the order that the data is stored in within the set is unimportant, and is in fact arbitrary.
An item in a SET can be a CHOICE of a number of alternatives. Such an item need not be explicitly named, but in this case each alternative of the choice must be named, and each must be unique amongst all other items within the entire SET. Alternatively, the SET item that is a CHOICE might indeed be named, and in this case only that name must be unique, as the CHOICE components are pushed to the next level in the component name hierarchy. For example, the following is valid:
Contact ::= SET {
name [4] GraphicString,
title [5] GeneralString,
businessNumber [6] NumericString,
CHOICE {
pagerNumber [1] NumericString,
homeNumber [2] NumericString
} ,
additionalContact [9] CHOICE {
pagerNumber [1] NumericString,
homeNumber [2] NumericString
}
}
This results in allowing the following component names to be referenced from NCL:
All SET items must be differentiated by an ASN.1 tag value. It is good practice to explicitly tag all SET items rather than default to tags of the ASN.1 base types.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |