Paul,
Paul Thorpe wrote:
...
> the note on
> X.683 clause
> 8.5 indicates that you might not be able to determine what that dummy
> parameter represents until the parameterized definition is used.
I don't get that impression from reading X.683, 8.5. It addresses the
case where the dummy parameter is disambiguated by its usage on the RHS
of the assignment, and it addresses the case where the dummy parameter
is disambiguated by its use as an actual parameter in a parameterized
reference on the RHS (where the corresponding dummy parameter for that
referenced thing is disambiguated), but it doesn't address the case
where neither of the above serve to disambiguate the dummy parameter.
I'm still left with the question of what to do in such cases.
I'm guessing that you're not in favour of rejecting such definitions,
but that still leaves me two possibilities. In effect it boils down to
(for example) whether the following definitions, taken collectively,
are correct ASN.1, or not:
Foobar { FOOBAR } ::= SEQUENCE {
field1 INTEGER (CONSTRAINED BY{ FOOBAR }) }
FoobarC ::= Foobar { TYPE-IDENTIFIER }
FoobarT ::= Foobar { INTEGER }
Regards,
Steven
