Hi,
If a standard allows for more than one interpretation, one can thus conclude
that the standard is:
a) ambiguous (on purpose, or by accident)
b) incomplete in its specification.
Any standard should strive to avoid the possibility of ambiguous
interpretation. :-). ( Not always easy).
Cheers,
Claude.
_____
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
This email address is being protected from spambots. You need JavaScript enabled to view it.
Sent: 24 April 2007 16:01
To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TciValue & TciType
Hi,
few comments with regards to tool independency. Although TTCN-3 standards
define the TRI and TCI there are some vendor specific interpretations with
regards to the TRI and the TCI functionality. These are details but in
practise the details cause some additional work. So, true plug-and-play is
not possible in practise today.
In addition, the fact that tool vendors use different target languages (C,
C++, Java etc.) causes integration problems if one wants to have one
executable. This can be solved by using multiple binaries that communicate
via sockets. However, sockets cause performance penalty which is sometimes
an undesired feature of this workaround.
My point is that even there are standard interfaces, interoperability is an
issue because of different interpretations of the standards.
BR,
Risto
_____
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 RTP Techie
Sent: 24 April, 2007 16:00
To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TciValue & TciType
Hi,
From what I understand, one of the objectives of standardizing TRI and TCI
is that TE can connect to any IUT using standard SA and can be managed by
any standard TM. If these two types are not standardized, we can not have
a true "plug-&-play" type of system. By that I meant if all the
interfaces/Types are defined, we can do the following totally independently:
1) Compile TTCN using Vendor X's compiler;
2) Running it using TM from Vendor Y.
3) Use a test tool from vendor Z to connect to IUT.
Right now Item-1 and Item-2 are coupled together by these couple of types.
Thanks,
RTP
On 4/24/07, Pusz, Mateusz <
This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
Hi
I had the same problem. These types are not used in TTCN environment
(TM, CD, TL, ...) by value. You have to pass them to TE with a set of
functions to obtain their data. Because of that they are ment to be
vendor specific.
I think it is not a good approach. For example if you plan to create
universal TM library (independent from other vendors) you have to
declare that values somehow. The problem is that these types are ment to
be abstract base classes of a large class hierarchy. As C language does
not support classes they can be defined only as 'void *' (it is the way
I declared them).
I filed 2 CRs on that:
- CR0000828 (
ipt-bugs.dyndns.org/mantis/view.php?id=828) - for
'void *' definition
- CR0000829 (
ipt-bugs.dyndns.org/mantis/view.php?id=829) - for
adding C++ language mappings
Best Regards
Mateusz Pusz
>
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 Stephan Schulz
>Sent: Tuesday, April 24, 2007 9:35 AM
>To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TciValue & TciType
>
>Hi,
>
>My understanding is that these types have not standardized on purposes
>.. But they have to be provided by TTCN-3 RTSes, i.e., data structures
>are tool proprietary.
>I guess the idea of the standard has been in these two cases to
>standardize _operations_ to access data structures instead of the data
>structures themselves. That enables you still to reuse TCI
>implementations with different tools.
>
>Salut,
>Stephan
>
>
>> TTCN3-User,
>> I'm going through TCI spec (Part-6) version 3.2.1 and I'm
>> interested in the C binding in Section 9.
>> But I don't see the C definition for TciValue and TciType?
>> Can someone tell me where to look them up or why they are
>not defined?
>>
>> Thanks,
>>
>> RTP
>
