Mark DeCoursey wrote:
>
> Benoit POSTE wrote:
>
> >
> > > Check elsewhere in your local production for the definition of
> > > informationFramework. It is likely to be a DefinedValue of type
> > > ObjectIdentifier, which should correspond to the OID of the module
> > > InformationFramework.
> >
> > You're right ... and it was right before my eyes (well, almost
> > before my eyes). Stupid me! Sorry, sorry, sorry. And thanks :).
>
> You're quite welcome. But I consider this a weak element in the
> Standard that I would like to see addressed.
Actually, this point is addressed in the standard (see below).
However, all remarks are welcome. The ISO and ITU-T ASN.1 Group is going to
review the X.680 and X.690 series in order to produce the next edition (2002)
of these standards. Please send your *editorial* remarks to me for discussion
and inclusion in this new release.
> When you have multiple imports:
>
> a b c d FROM E
> f g h i j k FROM L m;
>
> How do you tell whether f is added distinguishing identity of module E,
> OR
> is listed to be imported from module L?
Don't forget the commas and you've got your answer!
IMPORTS
a, b, c, d, FROM E
f, g, h, i, j, k FROM L m;
or
IMPORTS
a, b, c, d, FROM E f
g, h, i, j, k FROM L m;
> This seems to require reading all the symbols from local module and
> searching for f. If not found (among local or imported symbols), try to
> import it from L.
>
> My personal preference would be to forbid use of local DefinedValue in
> this place.
Please note that the ASN.1 Group would never do this, for it would break
existing ASN.1 specifications.
--
Olivier DUBUISSON (ITU-T ASN.1 Rapporteur)
france telecom R&D
_ DTL/MSV - 22307 Lannion Cedex - France
( ) tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
/.\/ --------------------------------------
\_/\ Site ASN.1 : http://asn1.elibel.tm.fr/
