Dear Antti,

please find my answers inline.

Antti Hyrkkanen wrote:
> Hello
>
> Relating an email of the last winter, is it legal that as the return
> value of TCI-CD operation
>
> Value decode(in TriMessageType message,
> in Type decodingHypothesis),
>
> the decoder returns a value, that is not compatible to decodingHypothesis?
>
> It is said in the standard, that it should return null if it cannot
> decode a compatible value.
Yes, this is right and this was the intentions.

> Now, how does the decoder know that the return
> value is incompatible with the decodingHypothesis, if the type is a subtype,
> whose values have been limited by range or a value list?
>
The easiest answers is:
By definition!

You are right concluding that with the operations available at the
AbstractDataType interface it would be hard to write arbitrary generic
codecs. However, this was not the primarily goal of the TCI.

The main purpose of the TCI value interface is to enable the codec to
build valid TTCN-3 values. If the decoder needs for this some "a priory"
knowledge it must be added separately.

> For example:
>
> type integer MyIntegerRange (1, 2, 3, 10 .. 20, 99, 100);
> type integer MyStrings ("Alice", "Bob");
>
> There is no operation with which the decoder could ask what are the legal
> values of for a certain type, nor there is no operation with which the
> the decoder could ask whether a certain value is compatible with the
> type of decodingHypothesis.
Right. A decoder should "know" that for MyIntegerRange only the
mentioned values are allowed.

In other words, for example the value "101" is not of type
MyIntegerRange in the same way as "true" is not of type integer but of
type boolean. (BTW: "Alice" and "Bob" are also no integers ;-) I do not
assume that you would need an operation that says that "true" is not of
type "MyIntegerRange"? A value is of a given type or not.

>
> Should all the the set* operations return an error value, when the
> codec tries to assign an illegal value for the type?
>
Right. On the other hand assuming that the decoder is "aware" of the
limitations according to the type system, there shouldn't be any
"invalid" calls to set*-operations.

> Or should there be a separate validate() operation, with which
> the codec could ask from the TE, whether the constructed value
> is compatible with the decodingHypothesis?

I don't thinks it is necessary. What would be the conclusion for the
decoder? To retry to decode the received value? I don't think that the
decoder should guess what he is decoding, but instead should be guided
by the decodingHypthesis while he is decoding. Any discrepancy between
the decodingHypothesis and the actual decoding can be interpreted that
the received value is not of the type as defined in TTCN-3.

> The only operations for EnumeratedValue type are
>
> TString getEnum() and
> void setEnum(in TString enumValue),
>
> which get and set the value by enumeration identifier. There is no method
> with which a decoder would get a list of the legal identifiers.
>
See above.

> At the core language level, the user can specify integer values associated
> with the string indentifiers. There are no methods for querying the
> associated integer value or for setting the EnumeratedValue by the
> integer value.
>
> "6.3.4 Enumerated type and values
>
> NOTE 1: The integer value also may be used by the system to
> encode/decode enumerated values. This, however is outside of the scope
> of the present document (with the exception that TTCN-3 allows the
> association of encoding attributes to TTCN-3 items). "
>

This quote is taken from the TTCN-3 core specification. We decided to
keep this also in TCI "outside" of TTCN-3.

Side note: In my personal opinion the quoted note is not really helpful
as of course there are many things that you can do with TTCN-3 which are
outside of the scope of TTCN-3. And of course you do not need to mention
them all. But as I said, this is my very personal opinion.

Best regards,

Theo

> Br
> Antti Hyrkkanen
>
>
>>

---

Original Message

---

>>From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
>>[This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Stephan Tobies
>>Sent: Thursday, December 11, 2003 13:06 PM
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: Decoding enumerated types
>
>
> <clip>
>
>>Now what happens when you receive a value that does not match your
>>specific chosen encoding [which is probably what you had in mind with
>>you question], that is simply a 'decoding error', which means that your
>>decoder should report that the value could not be decoded as the
>>expected type. This is not necessarily a test case error, but will
>>rather cause the receive statement to fail to match. If no default are
>>active and no guard timer exists, that means that you get a deadlock of
>>the receive statement, which _is_ a test case error.
>>
>>BR
>>
>>Stephan Tobies
>
>

Hello Theo

>
> > Now, how does the decoder know that the return
> > value is incompatible with the decodingHypothesis, if the type is a
subtype,
> > whose values have been limited by range or a value list?
> >
> The easiest answers is:
> By definition!
>
> You are right concluding that with the operations available at the
> AbstractDataType interface it would be hard to write arbitrary generic
> codecs. However, this was not the primarily goal of the TCI.

I was hoping, that it would be possible to write generic codecs, that
could be used with several types, and these codecs could be taken into use
and parameterized using the attribute mechanism. When the decode() operation
is called, I would use the attributes extracted from the decodingHypothesis
to determine which spesific decoders to call and with what parameters.

> The main purpose of the TCI value interface is to enable the codec to
> build valid TTCN-3 values. If the decoder needs for this some "a priory"
> knowledge it must be added separately.

I would not like to have the codecs to be dependent on a priori information
on the types. All the required information in my personal opinion should
be accessible via the decodingHypothesis, which would make the codecs
independent of any inside information, thus making them more generic.

For example if I rename a type, I think this should have no effect on
how the values of the type are encoded, as long as the encoding attributes
are the same.

> > For example:
> >
> > type integer MyIntegerRange (1, 2, 3, 10 .. 20, 99, 100);
> > type integer MyStrings ("Alice", "Bob");
> >
> > There is no operation with which the decoder could ask what are the
legal
> > values of for a certain type, nor there is no operation with which the
> > the decoder could ask whether a certain value is compatible with the
> > type of decodingHypothesis.
> Right. A decoder should "know" that for MyIntegerRange only the
> mentioned values are allowed.
>
> In other words, for example the value "101" is not of type
> MyIntegerRange in the same way as "true" is not of type integer but of

This is not in line with Ina's reply. She wrote that decoder does not
have to honor subtype restrictions as long as the base type/class is the
same. If my charstring type is limited to length of 10, my decoder
could return a string of length 1000.

> type boolean. (BTW: "Alice" and "Bob" are also no integers ;-)

You are right, that was there just to see if anyone was awake :*)


> > Should all the the set* operations return an error value, when the
> > codec tries to assign an illegal value for the type?
> >
> Right. On the other hand assuming that the decoder is "aware" of the
> limitations according to the type system, there shouldn't be any
> "invalid" calls to set*-operations.

See Ina's reply.

>
> > Or should there be a separate validate() operation, with which
> > the codec could ask from the TE, whether the constructed value
> > is compatible with the decodingHypothesis?
>
> I don't thinks it is necessary. What would be the conclusion for the
> decoder? To retry to decode the received value?

No, the decoder should give up and return null value, since it could
not decode a value compatible to the decodingHypothesis.

> I don't think that the decoder should guess what he is decoding, but
> instead should be guided by the decodingHypthesis while he is decoding.
> Any discrepancy between the decodingHypothesis and the actual decoding
> can be interpreted that the received value is not of the type as defined
> in TTCN-3.

I agree with this, but since one cannot get subtype information from the
hypothesis, I proposed ways with which the decoder would be guided in
decoding a legal TTCN-3 value. If Ina's answer was correct, then I don't
have to worry about the subtype restrictions of the values, so I don't
need the proposed validation function or return values for set*
operations.


> > The only operations for EnumeratedValue type are
> >
> > TString getEnum() and
> > void setEnum(in TString enumValue),
> >
> > which get and set the value by enumeration identifier. There is no
method
> > with which a decoder would get a list of the legal identifiers.
> >
> See above.
>
> > At the core language level, the user can specify integer values
associated
> > with the string indentifiers. There are no methods for querying the
> > associated integer value or for setting the EnumeratedValue by the
> > integer value.
> >
> > "6.3.4 Enumerated type and values
> >
> > NOTE 1: The integer value also may be used by the system to
> > encode/decode enumerated values. This, however is outside of the
scope
> > of the present document (with the exception that TTCN-3 allows the
> > association of encoding attributes to TTCN-3 items). "
> >
>
> This quote is taken from the TTCN-3 core specification. We decided to
> keep this also in TCI "outside" of TTCN-3.

Also from Core Language standard:

"
28.2.3 Special strings

The following strings are the predefined (standardized) variant
attributes for simple basic types (see clause E.2.1):

a) "8 bit" and "unsigned 8 bit" mean, when applied to integer and
enumerated types, that the integer value or the integer numbers
associated with enumerations shall be handled as it was represented on
8-bits (single byte) within the system.
..."

From that I also get the impression, that the integer value information
would be present to the codecs.

If I have defined

type enumerated Halogens
{
Fluorine (9), Chlorine (17), Bromine (35), Iodine (53), Astatine (85)
},

my encoder and decoder would be more interested in the integer value than
identifier string, when values of this type are sent back and forth
between my SUT.

Would there be problems in having TCI-CD operations like
getEnumAsInteger(), setEnumAsInteger()?

A codec for my Halogens type would need to have as built in / a priori the
information, that the enumerated type called "Halogens" has the integers
associated with the identifiers according to the table below, if this
information is not written into the encoding attributes:

Fluorine <-> 9
Chlorine <-> 17
Bromine <-> 35
Bromine <-> 53
Astatine <-> 85

If I change the type name of the "Halogens" to "GroupHalogens", the codec
cannot be used without changing its code, if the codec is type specific.
If I add a new enumeration value Unseptium (117) to Halogens, the codec
breaks again. It would not break if I could get a list of legal
identifiers and their integer values.

I know I could use the encoding attributes to make the codec independent
of the type name, but to me it looks like I'm writing the same information
twice:

type enumerated Halogens
{
Fluorine (9),
Chlorine (17),
Bromine (35),
Iodine (53),
Astatine (85)
} with
{
encode "EnumerationTable: Fluorine:9, Chlorine:17, Bromine:35,
Iodine:53, Astatine:85"
}

BR
Antti

Dear Antti,

I guess my first answer was typed too fast (and was short because I was
in a hurry ...) - still, I basically see two ways of dealing with
subtyping:

- the one proposed by Theo is indeed the more clean way from the TE
perspective - in that already the decoder ensures that a decoded value
belongs to a subtype

- the one I was thinking of (also guided by your writing) is that part
of the type checking could be given to the TE - but then we have so to
say a "dirty" intermediate situation - a decoded value is handled as
being of the base type and only then being checked for type compatibility

Looking into TCI-CD, it rather describes the first approach - still, it
leaves room for interpretation. For example, TCI states that

"decodingHypothesis The hypothesis the decoding can be based on."

or

"The decodingHypothesis shall be used to determine whether the encoded
value can be decoded. "

But it does not clearly states that the decoding hypothesis is always
the type - I would read in the light of this discussion that also the
base type could be used. However, this could now open the box of the
pandora: going the second option will have impacts on the TE which does
not really seem to be a good idea ... so, I rather guess one should make
TCI more clear in this matter.

Cheers, Ina.

Antti Hyrkkanen wrote:
> Hello Theo
>
>
>>>Now, how does the decoder know that the return
>>>value is incompatible with the decodingHypothesis, if the type is a
>
> subtype,
>
>>>whose values have been limited by range or a value list?
>>>
>>
>>The easiest answers is:
>>By definition!
>>
>>You are right concluding that with the operations available at the
>>AbstractDataType interface it would be hard to write arbitrary generic
>>codecs. However, this was not the primarily goal of the TCI.
>
>
> I was hoping, that it would be possible to write generic codecs, that
> could be used with several types, and these codecs could be taken into use
> and parameterized using the attribute mechanism. When the decode() operation
> is called, I would use the attributes extracted from the decodingHypothesis
> to determine which spesific decoders to call and with what parameters.
>
>
>>The main purpose of the TCI value interface is to enable the codec to
>>build valid TTCN-3 values. If the decoder needs for this some "a priory"
>>knowledge it must be added separately.
>
>
> I would not like to have the codecs to be dependent on a priori information
> on the types. All the required information in my personal opinion should
> be accessible via the decodingHypothesis, which would make the codecs
> independent of any inside information, thus making them more generic.
>
> For example if I rename a type, I think this should have no effect on
> how the values of the type are encoded, as long as the encoding attributes
> are the same.
>
>
>>>For example:
>>>
>>> type integer MyIntegerRange (1, 2, 3, 10 .. 20, 99, 100);
>>> type integer MyStrings ("Alice", "Bob");
>>>
>>>There is no operation with which the decoder could ask what are the
>
> legal
>
>>>values of for a certain type, nor there is no operation with which the
>>>the decoder could ask whether a certain value is compatible with the
>>>type of decodingHypothesis.
>>
>>Right. A decoder should "know" that for MyIntegerRange only the
>>mentioned values are allowed.
>>
>>In other words, for example the value "101" is not of type
>>MyIntegerRange in the same way as "true" is not of type integer but of
>
>
> This is not in line with Ina's reply. She wrote that decoder does not
> have to honor subtype restrictions as long as the base type/class is the
> same. If my charstring type is limited to length of 10, my decoder
> could return a string of length 1000.
>
>
>>type boolean. (BTW: "Alice" and "Bob" are also no integers ;-)
>
>
> You are right, that was there just to see if anyone was awake :*)
>
>
>
>>>Should all the the set* operations return an error value, when the
>>>codec tries to assign an illegal value for the type?
>>>
>>
>>Right. On the other hand assuming that the decoder is "aware" of the
>>limitations according to the type system, there shouldn't be any
>>"invalid" calls to set*-operations.
>
>
> See Ina's reply.
>
>
>>>Or should there be a separate validate() operation, with which
>>>the codec could ask from the TE, whether the constructed value
>>>is compatible with the decodingHypothesis?
>>
>>I don't thinks it is necessary. What would be the conclusion for the
>>decoder? To retry to decode the received value?
>
>
> No, the decoder should give up and return null value, since it could
> not decode a value compatible to the decodingHypothesis.
>
>
>>I don't think that the decoder should guess what he is decoding, but
>>instead should be guided by the decodingHypthesis while he is decoding.
>>Any discrepancy between the decodingHypothesis and the actual decoding
>>can be interpreted that the received value is not of the type as defined
>>in TTCN-3.
>
>
> I agree with this, but since one cannot get subtype information from the
> hypothesis, I proposed ways with which the decoder would be guided in
> decoding a legal TTCN-3 value. If Ina's answer was correct, then I don't
> have to worry about the subtype restrictions of the values, so I don't
> need the proposed validation function or return values for set*
> operations.
>
>
>
>>>The only operations for EnumeratedValue type are
>>>
>>> TString getEnum() and
>>> void setEnum(in TString enumValue),
>>>
>>>which get and set the value by enumeration identifier. There is no
>
> method
>
>>>with which a decoder would get a list of the legal identifiers.
>>>
>>
>>See above.
>>
>>
>>>At the core language level, the user can specify integer values
>
> associated
>
>>>with the string indentifiers. There are no methods for querying the
>>>associated integer value or for setting the EnumeratedValue by the
>>>integer value.
>>>
>>> "6.3.4 Enumerated type and values
>>>
>>> NOTE 1: The integer value also may be used by the system to
>>> encode/decode enumerated values. This, however is outside of the
>
> scope
>
>>> of the present document (with the exception that TTCN-3 allows the
>>> association of encoding attributes to TTCN-3 items). "
>>>
>>
>>This quote is taken from the TTCN-3 core specification. We decided to
>>keep this also in TCI "outside" of TTCN-3.
>
>
> Also from Core Language standard:
>
> "
> 28.2.3 Special strings
>
> The following strings are the predefined (standardized) variant
> attributes for simple basic types (see clause E.2.1):
>
> a) "8 bit" and "unsigned 8 bit" mean, when applied to integer and
> enumerated types, that the integer value or the integer numbers
> associated with enumerations shall be handled as it was represented on
> 8-bits (single byte) within the system.
> ..."
>
>>From that I also get the impression, that the integer value information
> would be present to the codecs.
>
> If I have defined
>
> type enumerated Halogens
> {
> Fluorine (9), Chlorine (17), Bromine (35), Iodine (53), Astatine (85)
> },
>
> my encoder and decoder would be more interested in the integer value than
> identifier string, when values of this type are sent back and forth
> between my SUT.
>
> Would there be problems in having TCI-CD operations like
> getEnumAsInteger(), setEnumAsInteger()?
>
> A codec for my Halogens type would need to have as built in / a priori the
> information, that the enumerated type called "Halogens" has the integers
> associated with the identifiers according to the table below, if this
> information is not written into the encoding attributes:
>
> Fluorine <-> 9
> Chlorine <-> 17
> Bromine <-> 35
> Bromine <-> 53
> Astatine <-> 85
>
> If I change the type name of the "Halogens" to "GroupHalogens", the codec
> cannot be used without changing its code, if the codec is type specific.
> If I add a new enumeration value Unseptium (117) to Halogens, the codec
> breaks again. It would not break if I could get a list of legal
> identifiers and their integer values.
>
> I know I could use the encoding attributes to make the codec independent
> of the type name, but to me it looks like I'm writing the same information
> twice:
>
> type enumerated Halogens
> {
> Fluorine (9),
> Chlorine (17),
> Bromine (35),
> Iodine (53),
> Astatine (85)
> } with
> {
> encode "EnumerationTable: Fluorine:9, Chlorine:17, Bromine:35,
> Iodine:53, Astatine:85"
> }
>
> BR
> Antti

--

---

Ina Schieferdecker url: www.fokus.fraunhofer.de/tip
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

Hi all,

I guess one of the final realizations from this discussion is that subtyping can currently only be checked in TCI-CD codecs
based on the subtype name/identifier.

I strongly agree with Antti that this is really restricting codec implementers in the implementation of dynamic codecs,
i.e., codecs which are not generated by some tool before compile time or handwritten in a hardcoded manner.
Think of the problem if Theo in his test suite decides to change his subtype name ... all of a sudden his codec implementation needs to be updated. Well if Antti would have had some access to the subtype information via the TCI-CD
then his codec implementation could still be used as is!

So since an extra TCI-CD operation from CD to TE is the simplest way to check such a thing then why not add it to this interface? Theo can still write his codecs based on the name. From a tool point of view that function must exist anyhow
in the TE implementation .. so what is such a big problem making this function visible to the CD?
Notice that such a function is already supported by at least one TTCN tool on the market .. and let me say that I do make use that function in my codecs. This interface improves and simplifies codec implementations!

That enumeration issue is really very much related - here also an extra TCI-CD operation would be in place. Yes - one could hardcode the values based on a enumeration type name - we know the drawbacks of this approach. Theo's proposed encoding attribute way is also a possibility but really cumbersome. It is also likely that you get much better codec performance if you call a TCI-CD function versus parsing a string or the value and then converting that substring to an integer. Also it unecessarily increases the size and complexity of the codec implementation.

Technically testing_tech could argue here that a type identifier would suffice instead of a complete type interface in the TCI-CD because "you can go ahead and hardcode all type related information in your codec implementation". I hope we all agree that this is is _not_ what we want from the TCI-CD!

I hope that CRs are already their way .. :)

Moikka,
stephan

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Antti Hyrkkanen
> Sent: 14 July, 2004 19:50
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: [info]: Validation of decoded values: RE: Decoding
> enumerated types
>
>
> Hello Theo
>
> >
> > > Now, how does the decoder know that the return
> > > value is incompatible with the decodingHypothesis, if the
> type is a
> subtype,
> > > whose values have been limited by range or a value list?
> > >
> > The easiest answers is:
> > By definition!
> >
> > You are right concluding that with the operations available at the
> > AbstractDataType interface it would be hard to write
> arbitrary generic
> > codecs. However, this was not the primarily goal of the TCI.
>
> I was hoping, that it would be possible to write generic codecs, that
> could be used with several types, and these codecs could be
> taken into use
> and parameterized using the attribute mechanism. When the
> decode() operation
> is called, I would use the attributes extracted from the
> decodingHypothesis
> to determine which spesific decoders to call and with what parameters.
>
> > The main purpose of the TCI value interface is to enable
> the codec to
> > build valid TTCN-3 values. If the decoder needs for this
> some "a priory"
> > knowledge it must be added separately.
>
> I would not like to have the codecs to be dependent on a
> priori information
> on the types. All the required information in my personal
> opinion should
> be accessible via the decodingHypothesis, which would make the codecs
> independent of any inside information, thus making them more generic.
>
> For example if I rename a type, I think this should have no effect on
> how the values of the type are encoded, as long as the
> encoding attributes
> are the same.
>
> > > For example:
> > >
> > > type integer MyIntegerRange (1, 2, 3, 10 .. 20, 99, 100);
> > > type integer MyStrings ("Alice", "Bob");
> > >
> > > There is no operation with which the decoder could ask
> what are the
> legal
> > > values of for a certain type, nor there is no operation
> with which the
> > > the decoder could ask whether a certain value is
> compatible with the
> > > type of decodingHypothesis.
> > Right. A decoder should "know" that for MyIntegerRange only the
> > mentioned values are allowed.
> >
> > In other words, for example the value "101" is not of type
> > MyIntegerRange in the same way as "true" is not of type
> integer but of
>
> This is not in line with Ina's reply. She wrote that decoder does not
> have to honor subtype restrictions as long as the base
> type/class is the
> same. If my charstring type is limited to length of 10, my decoder
> could return a string of length 1000.
>
> > type boolean. (BTW: "Alice" and "Bob" are also no integers ;-)
>
> You are right, that was there just to see if anyone was awake :*)
>
>
> > > Should all the the set* operations return an error value, when the
> > > codec tries to assign an illegal value for the type?
> > >
> > Right. On the other hand assuming that the decoder is "aware" of the
> > limitations according to the type system, there shouldn't be any
> > "invalid" calls to set*-operations.
>
> See Ina's reply.
>
> >
> > > Or should there be a separate validate() operation, with which
> > > the codec could ask from the TE, whether the constructed value
> > > is compatible with the decodingHypothesis?
> >
> > I don't thinks it is necessary. What would be the conclusion for the
> > decoder? To retry to decode the received value?
>
> No, the decoder should give up and return null value, since it could
> not decode a value compatible to the decodingHypothesis.
>
> > I don't think that the decoder should guess what he is decoding, but
> > instead should be guided by the decodingHypthesis while he
> is decoding.
> > Any discrepancy between the decodingHypothesis and the
> actual decoding
> > can be interpreted that the received value is not of the
> type as defined
> > in TTCN-3.
>
> I agree with this, but since one cannot get subtype
> information from the
> hypothesis, I proposed ways with which the decoder would be guided in
> decoding a legal TTCN-3 value. If Ina's answer was correct,
> then I don't
> have to worry about the subtype restrictions of the values, so I don't
> need the proposed validation function or return values for set*
> operations.
>
>
> > > The only operations for EnumeratedValue type are
> > >
> > > TString getEnum() and
> > > void setEnum(in TString enumValue),
> > >
> > > which get and set the value by enumeration identifier. There is no
> method
> > > with which a decoder would get a list of the legal identifiers.
> > >
> > See above.
> >
> > > At the core language level, the user can specify integer values
> associated
> > > with the string indentifiers. There are no methods for
> querying the
> > > associated integer value or for setting the
> EnumeratedValue by the
> > > integer value.
> > >
> > > "6.3.4 Enumerated type and values
> > >
> > > NOTE 1: The integer value also may be used by the system to
> > > encode/decode enumerated values. This, however is
> outside of the
> scope
> > > of the present document (with the exception that
> TTCN-3 allows the
> > > association of encoding attributes to TTCN-3 items). "
> > >
> >
> > This quote is taken from the TTCN-3 core specification. We
> decided to
> > keep this also in TCI "outside" of TTCN-3.
>
> Also from Core Language standard:
>
> "
> 28.2.3 Special strings
>
> The following strings are the predefined (standardized) variant
> attributes for simple basic types (see clause E.2.1):
>
> a) "8 bit" and "unsigned 8 bit" mean, when applied to integer and
> enumerated types, that the integer value or the integer numbers
> associated with enumerations shall be handled as it was
> represented on
> 8-bits (single byte) within the system.
> ..."
>
> From that I also get the impression, that the integer value
> information
> would be present to the codecs.
>
> If I have defined
>
> type enumerated Halogens
> {
> Fluorine (9), Chlorine (17), Bromine (35), Iodine (53),
> Astatine (85)
> },
>
> my encoder and decoder would be more interested in the
> integer value than
> identifier string, when values of this type are sent back and forth
> between my SUT.
>
> Would there be problems in having TCI-CD operations like
> getEnumAsInteger(), setEnumAsInteger()?
>
> A codec for my Halogens type would need to have as built in /
> a priori the
> information, that the enumerated type called "Halogens" has
> the integers
> associated with the identifiers according to the table below, if this
> information is not written into the encoding attributes:
>
> Fluorine <-> 9
> Chlorine <-> 17
> Bromine <-> 35
> Bromine <-> 53
> Astatine <-> 85
>
> If I change the type name of the "Halogens" to
> "GroupHalogens", the codec
> cannot be used without changing its code, if the codec is
> type specific.
> If I add a new enumeration value Unseptium (117) to Halogens,
> the codec
> breaks again. It would not break if I could get a list of legal
> identifiers and their integer values.
>
> I know I could use the encoding attributes to make the codec
> independent
> of the type name, but to me it looks like I'm writing the
> same information
> twice:
>
> type enumerated Halogens
> {
> Fluorine (9),
> Chlorine (17),
> Bromine (35),
> Iodine (53),
> Astatine (85)
> } with
> {
> encode "EnumerationTable: Fluorine:9, Chlorine:17, Bromine:35,
> Iodine:53, Astatine:85"
> }
>
> BR
> Antti
>

Sorry about that if this posting appears two or three times, having
hard time with Outlook :)

In response to Ina:

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Ina Schieferdecker
> Sent: Thursday, July 15, 2004 00:34 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: [info]: Validation of decoded values: RE: Decoding
> enumerated types
> Dear Antti,
>
> I guess my first answer was typed too fast (and was short because I was
> in a hurry ...) - still, I basically see two ways of dealing with
> subtyping:
>
> - the one proposed by Theo is indeed the more clean way from the TE
> perspective - in that already the decoder ensures that a decoded value
> belongs to a subtype

I agree that this is more clean way, but shouldn't the decoder then have
the means to ensure that what it has decoded value indeed is of the subtype,
without the need to have this subtype specific information built into the
decoder? This would allow better use of generic third party codecs, I think.
That third party probably has no idea what restrictions your types will
have.
One could reuse the same codecs in several projects, and save the time of
reimplementing them to contain the restrictions of the subtypes
of the new project.

BR
Antti