Steven Legg wrote:
>
> Folks,
>
> In trying to tie up some loose ends in my ASN.1 compiler implementation
> I've come across some situations where the interplay between
> parameterization
> and ambiguity in the notation becomes problematic. The ASN.1 specifications
> don't provide sufficient detail for me to determine how to resolve the
> problems.
>
[snip]
X.683:2002 8.4 do have a note on this too.
> --------------------------------------------------------------------------
>
> Consider this type definition:
>
> Foobar { FOOBAR } ::= SEQUENCE {
> field1 [1] INTEGER (CONSTRAINED-BY{ FOOBAR })
> }
>
> It isn't possible to decide whether FOOBAR is an information object class or
> a type from the type definition alone. It can only be determined when
> Foobar is referenced with actual parameters.
>
> Should such an ambiguous assignment be rejected outright, should it be
> disambiguated by its first usage, or should all references with either a
> type or a defined object class as the actual parameter be allowed ?
>
> Regards,
> Steven
This part wasn't addressed by my previous reply and I haven't been able
to find a 'solution' to the problem in the standards.
Maybe this is a candidate for a defect report?
PS. It is CONSTRAINED BY, not CONSTRAINED-BY.
/Egon
--
* Talura ApS * Phone: +45 43 52 50 00 *
* Baldersh�j 24 B * mailto:[EMAIL PROTECTED] *
* DK-2635 Ish�j * http://www.talura.dk *
