John,
Okay. Whew! :-)
So for my first example, PER would encode a presence bit in the preamble
bit-map for anOptionalThing, right, even though it is constrained to be
ABSENT? And it would always be set to 0 because a value for that component
is constrained to always be absent. For my second example, the presence bit
would always be set to 1 and that component would always be present, or have
a value. This is what I thought, but a colleague questioned this, which led
me to wonder...
Thanks!
Paul
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John
Larmouth
Sent: Wednesday, July 17, 2002 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [ASN.1] WITH-COMPONENTS creates new type or just
semantically constrains?
Paul Long wrote:
Paul,
I guess it depends on what you mean by a new type. (The term is not
actual defined in ASN.1, but is used in the introduction and in a
normal English way when talking about defining a new type from an old
one by tagging or subtyping.)
The text is clear that tagging and subtyping (**all** forms of
subtyping) do indeed produce a new type. The text is probably
slightly unclear on whether a simple A ::= B assignment creates a new
type A from the old type B, but that is the intended view (the term
new is missing from 15.1 and 16.1, but it is clear from other cases
that a new type is intended here also).
Whether two types are the same or different matters mainly for
a) the rules on when values with one type can be used
in DEFAULT as
values of the other type (or as actual parameters for a dummy parameter
defined with the other type, and
b) (if there is a value mapping between the two types)
whether the
encoding of mapped values is the same in some particular encoding rule.
For the rules on a) you need to refer to what is colloquially called the
semantic model. (Formally: Rules for type and value Compatibility -
Annex B in the 2002 version.) For the rules on b), you need to refer to
individual encoding rules.
One imporant point is that for the purposes of a) above, inner subtyping
is not treated differently from any other form of subtyping. You *are*
defining a new type, but value mappings exist between the old and new
types, and values defined using one as the governor can be used as
DEFAULT values for the other (provided they are in the mapped subset).
Now we turn to b) above with BER: BER totally ignores constraints. So
the encoding of the mapped values of a constrained type are always the
same as those of the unconstrained type.
Now we turn to b) above with PER: Here it is a little more complex.
Some constraints are PER-visible (such as INTEGER (1..7) ) and affect
the encoding. Others (including UTF8String (T | F) and inner
subtyping) are *not* PER-visible. What this means is that the mapped
values encode in exactly the same way as the corresponding values in the
unconstrained type.
So
To give you a briefer answer: Your examples are best considered as
defining a new type (with a subset of the values of the old type), but
with both BER and PER the encoding of the mapped values is the same for
both the new type and the old type.
This can actually be important for inner subtyping, as one of its main
uses is to define a basic class message from a full class message,
and easy interworking between full class and basic class systems clearly
requires that encoding rules should produce the same encoding for values
that are in both the basic class and full class messages. They do!
John L
I have questions about inner subtyping. Given these two type
definitions:
Parent ::= SEQUENCE
{
anOptionalThing INTEGER OPTIONAL,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing ABSENT }
does the WITH-COMPONENTS construct essentially create a new type, i.e.,
SEQUENCE
{
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
or does it merely apply a semantic constraint to the existing
type, i.e.,
the anOptionalThing is still syntactically OPTIONAL but its _value_ is
constrained to not be present? For a PER encoding, the question could be
stated as, is there a presence bit (set to 0) in the bit-map
preamble for
the anOptionalThing component, or is even its presence bit absent?
Likewise, would this:
Child ::= Parent WITH COMPONENTS { ..., anOptionalThing PRESENT }
result in this new type:
SEQUENCE
{
anOptionalThing INTEGER,
anotherOptionalThing INTEGER OPTIONAL,
aRequiredThing INTEGER
}
Paul Long
ipDialog, Inc.
--
Prof John Larmouth
Larmouth TPDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED
