Maybe my last answer was not so good!
It was factually correct, and the minimum change. However, I think the
spirit of your example is that the type filling the ANY is fully
determined by the value of errorId. Yes?
In that case, you would be better to use the built-in class
TYPE-IDENTIFIER, which has two fields, an &id field that is an OID that
identifies the type in the ANY, and an &Type field that defines the type
for that OID.
This would give you:
XXArg ::= SEQUENCE {
errorId TYPE-IDENTIFIER.&id,
cause TYPE-IDENTIFIER.&Type OPTIONAL}
You can then (but need not!) go on to specify that the cause is
determined by the errorId using a Table which gives OID values and
corresponding types (a set of objects of class TYPE-IDENTIFIER):
XXArg ::= SEQUENCE {
errorId TYPE-IDENTIFIER.&id ({Table}),
cause TYPE-IDENTIFIER.&Type ({Table} {@erroId} )OPTIONAL}
There is then the question of whether the types and OID values are
specified (or partly specified) in your standard. If they are wholly
implementation-dependent, then you need:
Table ::= { ... }
to indicate that Table is not standardised, and that tools need to
invoke some run-time procedures to find out what id values and what
corresponding types a particular implementation supports.
Finally (if you are still reading this!), it may be that your "Error"
type is in fact an INTEGER (or even something more complicated, giving
severity as well as an id) rather than an Object Identifier. In this
case, you will need to define your own class instead of using the
built-in TYPE-IDENTIFIER class, but the principles above still stand.
John L
