Hi,

Please note first of all that the brackets in the with syntax are
permitted only if corresponding field is OPTIONAL.  In this case, neither
field is optional, so the brackets would not be permitted.  If you add
"OPTIONAL" to both fields, the WITH SYNTAX would not be permitted since
both values begin with the same token "{".

----------------------------------------------------------------------------
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 Thu, 5 Oct 2006, Ramaswamy R wrote:

> I have a clarification with the clause 10.12.b in X.681 (stated towards the
> end of the text).
>
> Consider the following class definition
>
> MY-CLASS ::= CLASS
> {
> &val1    SEQUENCE { ... } -- Resembling value of type REAL,
> &val2    REAL
> }
> WITH SYNTAX
> {    [&val1] [&val2]   }
>
> In case the object is specified as { 0 }, then we do no have any ambiguity.
> But what if the object is specified with a value resembling that of REAL?
>
> Does the clause mean that when there is a potential ambiguity between the
> values, the new syntax is illegal? This would allow certain combinations of
> types and disallow others.
> OR
> Does the clause mean that &val1 and &val2 cannot be of the same type?
> OR
> Does the clause mean that syntax should be such that only a specific Setting
> is expected at any point during parsing the same?
>
> Kindly carify on the same. Thanking you.
>
> Yours Sincerely
> Ramaswamy
>
>
>
> ------------------------------
> 10.12 In order to ensure easy parsing of the new syntax and to prevent
> abuses, the following additional restrictions
> are placed on the definer of new syntax:
>
> a) Every "OptionalGroup" is required to have at least one
> "PrimitiveFieldName" or "OptionalGroup" within it.
> NOTE 1 ? This is to help prevent the apparent collection of information
> which is not reflected in any field of the information object.
> b) The use of "OptionalGroup"s shall be such that at no time in the parsing
> process can a "Setting" appear that could potentially be a setting for more
> than one "FieldName".
> c) If an "OptionalGroup" starts with a "Literal", then the first token
> following the "OptionalGroup" shall also be a "Literal" and shall be
> different from the first "Literal" of all immediately preceding
> "OptionalGroup"s,
>
> while the following restriction is placed upon the user of the
> "DefinedSyntax":
> d) Whenever a "Literal" is present in a "DefinedSyntax" that occurs in an
> "OptionalGroup" a "Setting" for a "PrimitiveFieldName" in that
> "OptionalGroup" shall also be present.
> NOTE 2 ? This is to help prevent the apparent collection of information
> which is not reflected in any field of the information object.
> NOTE 3 ? The following example is a legal syntax but restriction d) prevents
> the user from writing LITERAL without following it by one or both of the
> optional groups:
> [LITERAL [A &field] [B &field2]]
> ------------------------------
>
> --
> "Chaos is the rule in nature, not an exception"
>
_______________________________________________
Asn1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1

Reply via email to