Patrick Henry wrote:
>>>>>>
It is also called a "hole", sometimes... (If I had the Rec. in front of
me, I could give you the precise wording,
sorry :-( As I say, I've also seen the expression "open type" used to
describe the type which contains the hole.
So, 'MyFunction', in addition to being parameterized, is also "open" in
the sense that it contains a hole, which is
filled in, by the compiler, using "information" from the object-set,
when you create a value for MyFunction. At
least, that is how I imagine it happens :-)
No, 'opcode' is a "object class field type"; its values are defined by
the field 'FUNCTION.&code' of the object-set
'Funct'. In this case, 'opcode' would be an INTEGER type whose values
have been constrained to be either 1 or 2.
The interesting thing about information object classes is the ability to
require that "parameters" used to complete
the definition come from the same row of the object set. This is
accomplished by the {@opcode} expression, which is
said to relate &code and &ArgumentType.
<<<<<<<<
First, the term "hole" probably originates from me, but is (I am close
to 100% certain) never used in the Standards. It refers to part of a
type definition that is not self-identifying. In BER the contents of
the "hole" are required to be BER encoded, so the BER TLV enables the
end to be found, but any TLV (with any semantics) can do in the "hole",
and additional information (typically, but not necessarily, an OID in
some other field of the same PDU) identifies the hole contents and its
semantics.
The term "open-type" *is* used in the Standards, and refers specifically
to occurrences of a reference (typically as an element of a sequence) to
a field of an information object class that is a type field - that is,
that can contain any ASN.1 type. (Such as an element of a sequence
whose type is defined as your FUNCTION.&Argument).
The term is applied specifically to the reference to a type field of an
information object class, and should *never* be applied to any enclosing
sequence that contains such a reference. This is because the term
"open-type" is formally used in the standard, and the encoding of such a
type is different (in PER) from that of the type present in the
definition of the corresponding information object field.
In PER, which normally relies on knowledge of the type of the next
element to find its length, an open type (where the actual type encoded
my only be determined by a *later* element), is given an additional
length wrapper, so that a decoder can find its end, possibly before it
gets the information saying which information object, and hence which
type has been encoded. To describe a sequence which contained an
"open-type" as itself an open-type is first in contradiction to the
Standard's use of the term, and is secondly VERY misleading, because
such a sequence type does NOT (of course) get an extra length wrapper in
PER, as it does not need one.
Open-types in pre-1984 ASN.1 were identified with the syntax "ANY", and
were indeed described as "an ANY type".
Parameterisation is a wholly different story, and a parameterised type
should never be confused with an open type, although the information
object set that frequently constrains the contents of an open type is
often a parameter of the enclosing structure.
Parameterisation can occur when there is no involvement of open types at
all. Equally, open types can occur without any use of parameterisation.
All Standardised encoding rules apply encodings *only* to
*instantiations* of parameterised types, when the parameterised type is
effectively replaced (and encoded) with all dummy parameters replaced by
actual parameters.
Hope this helps to clarify terminology and encodings. If you got any
other impresssion from my book, I had better re-write it!
John L
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED]
Cheshire WA14 3LS Tel: +44 161 928 1605
England Fax: +44 161 928 8069
