Hi Ramaswamy, Please refer to subclauses 46.6 and 46.8 of X.680 (2002):
46.6 When performing set arithmetic within a subtype constraint or a value set when the governing type is extensible, only abstract values that are in the extension root of the governing type are used in the set arithmetic. In this case, all instances of value notation (including value references) used in set arithmetic are required to reference an abstract value of the extension root of the governing type. The end-points of a range constraint are required to reference values that are present in the extension root of the governing type, and the range specification as a whole references all (and only) those values in the range that are within the extension root of the governing type. 46.8 If a subtype constraint is serially applied to a parent type which is extensible through the application of an extensible constraint, value notation used within it shall not reference values that are not in the extension root of the parent type. The result of the second (serially applied) constraint is defined to be the same as if the constraint had been applied to the parent type without its extension marker and possible extension additions. EXAMPLE Foo ::= INTEGER ( 1..6, ..., 73..80) Bar ::= Foo (73) -- illegal foo Foo ::= 73 -- legal since it is value notation for Foo, not part of a constraint Bar is illegal since 73 is not in the extension root of Foo. If 73 had been in the extension root of Foo, the example would have been legal, and Bar would have contained the single value of 73. These indicate that your IntersectionTest and ConstraintedType2 definitions are illegal, but your ConstrainedType1 is valid. ---------------------------------------------------------------------------- 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 Fri, 27 Jun 2003, Ramaswamy wrote: > Hi, > There are some clatifications that I have on constraint combinations. Pls > observe the ASN.1 spec snippet below - > > -------------------------------------------------------------------------------- > > IntersectionTest ::= INTEGER (0..100, ..., 101..150)(0..50, ..., 51..150) > -------------------------------------------------------------------------------- > > Is the resultant constraint the intersection of these two constraints?? As such > the ASN.1 spec does not permit intersection of ElementSetSpecs but only b/w the > elements within ElementSetSpecs. So how is the above to be interpreted. On the same > grounds I would like to have more clarity on the following as well. > > > -------------------------------------------------------------------------------- > > ConstrainedType1 ::= INTEGER (-300<..300, ...)(-250<..250, ..., -300<..290 | > 290<..300) > > ConstrainedType2 ::= INTEGER (-400<..400, ..., -1000<..-800 | 800<..1000) > (-950<..-850 | 850<..950, ..., -250<..250) > > -------------------------------------------------------------------------------- > > > Thanking you. > > Yours Sincerely > Ramaswamy > > -------------------------------------------------------------------------------- > "Any intelligent fool can make things bigger, more complex, and more violent. It > takes a touch of genius -- and a lot of courage -- to move in the opposite > direction." - Albert Einstein > > -------------------------------------------------------------------------------- > Information contained and transmitted by this E-MAIL is proprietary to > Synergy Infotech Private Limited and is intended for use only by the > individual or entity to which it is addressed, and may contain information > that is privileged, confidential or exempt from disclosure under applicable > law. If this is a forwarded message, the content of this E-MAIL may not have > been sent with the authority of the Company. If you are not the intended > recipient, an agent of the intended recipient or a person responsible for > delivering the information to the named recipient, you are notified that any > use, distribution, transmission, printing, copying or dissemination of this > information in any way or in any manner is strictly prohibited. We have taken > precautions to minimize the risk of transmitting software viruses, but we > advise you to carry out your own virus checks on any attachment to this > message. We cannot accept liability for any loss or damage caused by software > viruses. If you have received this communication in error, please delete this > mail & notify us immediately at mailto:[EMAIL PROTECTED] >
