Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Validation of decoded values: RE: Decoding enumerated types

Validation of decoded values: RE: Decoding enumerated types 14 Jul 2004 11:24 #6729

  • Antti Hyrkk
  • Antti Hyrkk's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 43
  • Karma: 0
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. 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?

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.

Should all the the set* operations return an error value, when the
codec tries to assign an illegal value for the type?

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?


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.

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). "


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
The administrator has disabled public write access.

Validation of decoded values: RE: Decoding enumerated types 14 Jul 2004 12:08 #6730

Dear Antti,

sorry to give a very short answer only: the decoder looks into data only
structurally - i.e. it can decode when the decodingHypothesis matches
the base type. The subtype limitations need to be handled by TE in
course of the matching.

With best regards,

Ina.

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. 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?
>
> 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.
>
> Should all the the set* operations return an error value, when the
> codec tries to assign an illegal value for the type?
>
> 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?
>
>
> 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.
>
> 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). "
>
>
> 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

--
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
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin