Hi together,

the ANYTYPE has been requested in order
to be IDL compatible.

Find enclosed a proposal for the ANYTYPE.

Comments are wellcome.

Regards
Jens Grabowski

hi all,

I have some comments regarding 'any', having myself some experience in
both using and implementing it:

I agree with the idea of handling open type values like unions of TTCN,
but would like to question the necessity of introducing the TTCN type
'anytype', into the language. I would propose to omit the facility of
defining open types out of TTCN, and use the TTCN notation for
referencing types for accessing the type. Having imported a type 'T', I
would reference the type of open type field 'o' as follows:

T.o

Referenced like this, not as an 'anytype', the type is correct because,
e.g.
the ASN.1 open type may be restricted, and may be different than the
union of all known types.

To me the deciding question for including the 'anytype' in the language
is if there is any use for it for the purpose of testing, to:
- check that a value is of 'anytype',
- send a value of 'anytype',
- store a value of 'anytype',
- reference a value of 'anytype'.

As I see only the last action as meaningful, I would reason that the
existence of this type is the result of the way the data specifications
are written and that the type itself is not necessary in TTCN. Having
already a way to reference those types, I don't see why they should be
introduced into the TTCN type system.

Union access seems appropriate for handling values of open types,
although the BNF (revision 2002) seems to delete the operator
'IsChosen'. Satisfied with these facilities, I would define the
referenced open types in TTCN only by saying 'open or any types are used
as union types of TTCN, with the name of the selected type in place of
the union selector identifier'.

regards,
Martti Söderlund

--
This email address is being protected from spambots. You need JavaScript enabled to view it.
Nokia Research Center


ext Jens Grabowski wrote:
>
> Hi together,
>
> the ANYTYPE has been requested in order
> to be IDL compatible.
>
> Find enclosed a proposal for the ANYTYPE.
>
> Comments are wellcome.
>
> Regards
> Jens Grabowski
>
>

---

> Name: any-type.doc
> Type: WINWORD File (application/msword)
> any-type.doc Encoding: base64
> Description: any-type.doc
> Download Status: Not downloaded with message

--
Martti Söderlund
This email address is being protected from spambots. You need JavaScript enabled to view it.
Nokia Research Center / Mobile Networks Laboratory

Hello,

my name is Andreas Hoffmann. I am a member of the test group of FOKUS
lead by Ina Schieferdecker. I would like to contribute to the discussion
on the any type in TTCN.

>>
>> To me the deciding question for including the 'anytype' in the language
>> is if there is any use for it for the purpose of testing, to:
>> - check that a value is of 'anytype',
>> - send a value of 'anytype',
>> - store a value of 'anytype',
>> - reference a value of 'anytype'.
>>
>> As I see only the last action as meaningful, I would reason that the
>> existence of this type is the result of the way the data specifications
>> are written and that the type itself is not necessary in TTCN. Having
>> already a way to reference those types, I don't see why they should be
>> introduced into the TTCN type system.
>>
It might be the case that the any type is not urgently needed for testing based on pure TTCN-3 technology and tools. But, please have in mind that one will have trouble with mappings from other descriptive languages such as OMG IDL to TTCN-3.
Since TTCN-3 seems to be well-designed for testing operation-based distributed systems based on CORBA-middleware, I think it is important to harmonize the type systems of TTCN-3 and OMG IDL in such a way that a native mapping between them is possible. Otherwise one will have trouble with automatizing mappings and implementing test tool chains.

To my mind the currently proposed mapping of the any type of OMG IDL to the union type of TTCN-3 is not a proper solutions since the type identifier describing the content of the any type will be lost. I would thus propose to introduce an any type to the TTCN-3 type system.

Regards
Andreas

====================================================================
Andreas Hoffmann
Fraunhofer FOKUS - Research Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31
D - 10589 Berlin

Phone: +49 30 3463-7392
Fax: +49 30 3463-8392
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
====================================================================

hi,

as I see it, external types have only a certain set of common properties
available when they are brought to TTCN. To me it seems when forming
this mapping, the alternatives are either:

- bring the features of the type systems into TTCN,
- keep the features out of TTCN.

In IDL there is an implicit type identifier that is carried in the any
type value, but in ASN.1 there is none. What's more IDL has a 'TypeCode'
identifier. The decision has to be made what is brought into TTCN, and
that should be balanced among the external data definition languages to
cover what is meaningful in testing.

Having an IDL 'any' type in an operation would allow a code generator to
insert a dynamic check for the type code and a conversion operation,
whereas the ASN.1 'any' type (X.208 version) would have to be handled
manually. Using a TTCN 'any' type in form of the current proposal would
probably be more difficult to handle automatically than either ASN.1 or
IDL 'any' types.

I would keep the 'any' type _definition_ facility out of TTCN, because
it is a facility that prevents automatic handling. I think it's still
possible to reference the external type and use it to provide automatic
handling.

br,
Martti Söderlund
--

This email address is being protected from spambots. You need JavaScript enabled to view it.
Nokia Research Center

ext Andreas Hoffmann wrote:
>
> Hello,
>
> my name is Andreas Hoffmann. I am a member of the test group of FOKUS
> lead by Ina Schieferdecker. I would like to contribute to the discussion
> on the any type in TTCN.
>
> >>
> >> To me the deciding question for including the 'anytype' in the
> language
> >> is if there is any use for it for the purpose of testing, to:
> >> - check that a value is of 'anytype',
> >> - send a value of 'anytype',
> >> - store a value of 'anytype',
> >> - reference a value of 'anytype'.
> >>
> >> As I see only the last action as meaningful, I would reason that the
> >> existence of this type is the result of the way the data
> specifications
> >> are written and that the type itself is not necessary in TTCN. Having
> >> already a way to reference those types, I don't see why they should
> be
> >> introduced into the TTCN type system.
> >>
> It might be the case that the any type is not urgently needed for
> testing based on pure TTCN-3 technology and tools. But, please have in
> mind that one will have trouble with mappings from other descriptive
> languages such as OMG IDL to TTCN-3.
> Since TTCN-3 seems to be well-designed for testing operation-based
> distributed systems based on CORBA-middleware, I think it is important
> to harmonize the type systems of TTCN-3 and OMG IDL in such a way that
> a native mapping between them is possible. Otherwise one will have
> trouble with automatizing mappings and implementing test tool chains.
>
> To my mind the currently proposed mapping of the any type of OMG IDL to
> the union type of TTCN-3 is not a proper solutions since the type
> identifier describing the content of the any type will be lost. I would
> thus propose to introduce an any type to the TTCN-3 type system.
>
> Regards
> Andreas
>
> ====================================================================
> Andreas Hoffmann
> Fraunhofer FOKUS - Research Institute for Open Communication Systems
> Kaiserin-Augusta-Allee 31
> D - 10589 Berlin
>
> Phone: +49 30 3463-7392
> Fax: +49 30 3463-8392
> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> ====================================================================