Sorry, re my mention of possible unclarity in the "A::=B" and clauses
15.1 and 16.1, I missed the following in Annex B:
>>>>
B.2.1 The underlying model is of types, as non-overlapping containers,
that contain values, with every occurrence of the ASN.1 "Type" construct
defining a distinct new type (see Figures B.1 and B.2).
<<<<
This confirms the interpretation I gave below: A is a new type, defined
from B, but with the same set of values, and with a value mapping
between the two types.
John L
John Larmouth wrote:
>
> 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 T&PDS Ltd
> (Training and Protocol Development Services)
> 1 Blueberry Road
> Bowdon [EMAIL PROTECTED]
> Cheshire WA14 3LS Tel: +44 161 928 1605
> England Fax: +44 161 928 8069
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon [EMAIL PROTECTED]
Cheshire WA14 3LS Tel: +44 161 928 1605
England Fax: +44 161 928 8069
