Hi Ramaswamy,

Please note that Annex B is purely for saying which types are compatible
so that a value of one type can be used as a value of some other type.
This annex does NOT specify that these transformations must be done before
you decide how automatic tagging should be done for determining how to
encode or decode values of a type.  That is spelled out in the SET,
SEQUENCE and CHOICE clauses in the main body of X.680 and is based purely
on the textual order of the components in them.

----------------------------------------------------------------------------
Paul E. Thorpe                                 Toll Free    : 1-888-OSS-ASN1
OSS Nokalva                                    International: 1-732-302-0750
Email: [EMAIL PROTECTED]                          Tech Support : 1-732-302-9669
http://www.oss.com                             Fax          : 1-732-302-0023

On Mon, 23 Jun 2003, Ramaswamy wrote:

> Hi,
>     S the syntax checker that I mentioned does the semantic checks as well
> :-). I did try with AUTOMATIC TAGS as well and the results are the same. One
> mistake from my part is that I did not consider that only the
> RootComponentTypeList is sorted, and not the extensions. My point is that in
> the book ASN.1 - Communication by Heterogeneous System, in the section on
> semantic model of ASN.1 it is mentioned that the ordering of the fields must
> be done before the decision on tagging is done so the tags must match is my
> understanding is correct.
> 
> Let me again explain with an e.g. -
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Junk DEFINITIONS AUTOMATIC TAGS ::=
> BEGIN
> 
> Choice1 ::= CHOICE
> {
>  f1  INTEGER,
>  f2  REAL
> }
> 
> Choice2 ::= CHOICE
> {
>  f2  REAL,
>  f1  INTEGER
> }
> 
> choice1 Choice1 ::= f1:10
> 
> choice2 Choice2 ::= choice1
> 
> ExtChoice1 ::= CHOICE
> {
>     field1  INTEGER,
>     field2  INTEGER,
>     ...,
>     field3  REAL,
>     field4  INTEGER
> }
> 
> ExtChoice2 ::= CHOICE
> {
>     field1  INTEGER,
>     field2  INTEGER,
>     ...,
>     field4  INTEGER,
>     field3  REAL
> }
> 
> ExtChoice3 ::= CHOICE
> {
>     field1  INTEGER,
>     field2  INTEGER,
>     ...,
>     field3  NumericString,
>     field4  INTEGER
> }
> 
> ext-choice1 ExtChoice1 ::= field2:10
> 
> ext-choice2 ExtChoice2 ::= ext-choice1
> 
> ext-choice3 ExtChoice3 ::= ext-choice1
> 
> END
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> Now the types Choice1 & Choice2 should be compatible according to the
> semantic model of ASN.1. But it says that the stmt 'choice2 Choice2 ::=
> choice1' is illegal (type-mismatch). But it does not report this for the
> stmt 'ext-choice2 ExtChoice2 ::= ext-choice2'. I do not understand why this
> behavious. Kindly advise.
> 
> Thanking you.
> 
> Yours Sincerely
> Ram
> 
> 

Reply via email to