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

TOPIC:

Change Requests on PTCC website 10 Jul 2002 08:48 #6151

FYI all the current CRs ( Change Requests) and the CR Status List on TTCN-3
v.2.0.0 can be found on:

www.etsi.org/ptcc/Change_request/ptccttcn3cr.htm

Regards,
Anthony
__________________________________________________
Anthony Wiles
Manager
ETSI Protocol and Testing Competence Centre (PTCC)

Route des Lucioles
F-06921 Sophia Antipolis Cedex
FRANCE

tel: +33 (0)4 92 94 43 87
gsm: +33 (0)6 85 41 72 75
fax: +33 (0)4 92 38 52 87

www.etsi.org/ptcc
__________________________________________________

Please Log in to join the conversation.

Change Requests on PTCC website 10 Jul 2002 10:11 #6152

Hi Anthony,

Did you receive the CRs which I sent to you in early June?

Cheers,

Claude.

PS: Here they are again.
Attachments:

Please Log in to join the conversation.

Change Requests on PTCC website 11 Jul 2002 08:43 #6153

Hi Claude,
Sorry to interupt your holiday, but i have a couple of TTCN
2 questions.
Can you have a test suite with no PCOs? Or do you get one implicit PCO if
none are defined?

If there is no MTC defined, but more than one PCO is defined, then would the
default / implicit MTC use all the PCOs? i.e. NumPcosUsed > 1. Is this a
valid possibility ?

If more than one MTC components definitions exist, then a configuration must
be associated with a test case in order to determine the MTC to use. Is this
correct ?



Is this assumption correct : If more than one PCO exists, then a test case
must be associated with a configuration identifying which PCOs it is using.

By this requirement, can there be no configuration with no MTC and multiple
PCOs in a test suite?

Thanks

Wayne

Original Message
From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 10 July 2002 11:11
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Change Requests on PTCC website



Hi Anthony,

Did you receive the CRs which I sent to you in early June?

Cheers,

Claude.

PS: Here they are again.

Please Log in to join the conversation.

Change Requests on PTCC website 18 Jul 2002 11:51 #6157

Hi Wayne!

I took the liberty of answering your questions... Hope that is ok;-) See my
answers below.

Original Message
From: Wayne Elliott [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 11 juli 2002 10:43
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Change Requests on PTCC website


Hi Claude,
Sorry to interupt your holiday, but i have a couple of TTCN
2 questions.
Can you have a test suite with no PCOs? Or do you get one implicit PCO if
none are defined?

There always has to be at least one PCO declaration in a test suite using
the dynamic part for sending and receiving ASPs/PDUs, however if you have
declared one PCO (and the PCO type) only you don't need to state the name of
the PCO when sending and receiving your message.

i.e.

! PDUSend PDUSend_c

? PDURec PDURec_c P

is allowed.



If there is no MTC defined, but more than one PCO is defined, then would the
default / implicit MTC use all the PCOs? i.e. NumPcosUsed > 1. Is this a
valid possibility ?

According to the test methods presented in 9646-2 you are only allowed to
have one PCO on the LT side and one PCO on the UT side of your tester (if
you use a non-concurrent approach). Some tools e.g. Telelogic Tau TTCN Suite
allows you to have several PCOs on both UT and LT side though. Note that
this applies for every PCO type in a non-concurrent architecture.

If more than one MTC components definitions exist, then a configuration must
be associated with a test case in order to determine the MTC to use. Is this
correct ?

Yes this is correct. The configuration used is determined by stating the
name of the configuration in the test case (MTC) header.



Is this assumption correct : If more than one PCO exists, then a test case
must be associated with a configuration identifying which PCOs it is using.

Again if you use the tools mentioned above (or similar with those
capabilities) you don't need to use a concurrent architecture to do this and
hence no configuration. According to the standard you need to do this though
if you use a concurrent approach.

By this requirement, can there be no configuration with no MTC and multiple
PCOs in a test suite?
See my answer above, it is tool dependent. If you follow the standard the
answer is no. Configurations are closely connected to the use of MTCs/PTCs.
There at least has to be one MTC if you use a concurrent architecture and
the you must define which configuration you are using as well.

Thanks

Wayne

BR

/Stefan

Original Message
From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 10 July 2002 11:11
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Change Requests on PTCC website



Hi Anthony,

Did you receive the CRs which I sent to you in early June?

Cheers,

Claude.

PS: Here they are again.

Please Log in to join the conversation.

Change Requests on PTCC website 26 Jul 2002 09:50 #6167

Hi Claude,

please note the array notation

var integer myVar[2,3]

is not allowed in TTCN-3. The only way to specify multi-demensional
arrays is

var interger myVar[2][3]

Secondly the only allowed syntax for initilising these arrays is

var interger myVar[2][3]:= {{1, 2, 3}, {11, 12, 13}}

With this in mind I see no need to define if it is row-major or column
major.

BR Colin.

p.s. the first point should be clear from the standard the second needs
to be clarified explicitly

Original Message
From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 10 July 2002 12:11
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Change Requests on PTCC website



Hi Anthony,

Did you receive the CRs which I sent to you in early June?

Cheers,

Claude.

PS: Here they are again.

Please Log in to join the conversation.

Change Requests on PTCC website 26 Jul 2002 10:42 #6168

In einer eMail vom 7/26/02 11:55:32 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


>
> Hi Claude,


Hi Colin,

Thanks for the clarifications.


>
> please note the array notation
>
> var integer myVar[2,3]
>
> is not allowed in TTCN-3.

Per BNF productions:

> 429. ArrayDef ::= {"[" ArrayBounds [".." ArrayBounds] "]"}+
> 430. ArrayBounds ::= SingleConstExpression
> /* STATIC SEMANTICS - ArrayBounds will resolve to a non negative value of
> integer type */
>
Just a question:

Should there not be a STATIC SEMANTIC restriction that the lower bound value
is
less than or equal to the upper bound value? or is the following also valid?
According
to the BNF it is:

var integer MyDecrementalArray[ 100 .. 5] [ 3 ..3 ]



Section 6.5 Arrays on page 33 of ES 201 873-1 (V2.2.0) states:

var integer MyArray2[ 2,3 ]

The example should be corrected accordingly.

A bit further in the text there is the example:

var integer MyArray4[1..5][2..3].

The only way to specify multi-demensional arrays is
>
>
> var interger myVar[2][3]
>

Agreed.

>
> Secondly the only allowed syntax for initilising these arrays is
>
> var interger myVar[2][3]:= {{1, 2, 3}, {11, 12, 13}}
>
> With this in mind I see no need to define if it is row-major or column
> major.
>
Even from this example it is not clear whether you have two rows of three
columns
or 2 columns of three rows, i.e. [row] [column] or [column] [row]

e.g. 1, 2, 3 or 1 11
11, 12, 13 2 12
3 13

Even if you think it is not needed, I think a clarification would not hurt.
Comments?
My thought on this is that if we make the storage representation clear to
everyone,
the likelihood that two different tool manufacturers interpret this
differently becomes 0.

>
> BR Colin.
>
> p.s. the first point should be clear from the standard the second needs to
> be clarified explicitly
>

Please Log in to join the conversation.

Change Requests on PTCC website 26 Jul 2002 11:05 #6169

Dear Claude,

>
> Even from this example it is not clear whether you have two rows of
> three columns
> or 2 columns of three rows, i.e. [row] [column] or [column] [row]
What is it good for?

>
> e.g. 1, 2, 3 or 1 11
> 11, 12, 13 2 12
> 3 13
>
> Even if you think it is not needed, I think a clarification would not
> hurt. Comments?
Hmmmm. Although I always favour clarification it is unclear to me, WHAT
should WHY clarified.

> My thought on this is that if we make the storage representation clear
> to everyone,
> the likelihood that two different tool manufacturers interpret this
> differently becomes 0.
Is there a discussion what
myVar[1][2]
(in your example) returns?

I would assume 13

Best regards,

Theo


>
>>
>> BR Colin.
>>
>> p.s. the first point should be clear from the standard the second
>> needs to be clarified explicitly
>
>
>

Please Log in to join the conversation.

Change Requests on PTCC website 26 Jul 2002 12:20 #6170

Dear Theo,

the notation for specifying values for multi-dimensional arrays
needs to be clarified in the TTCN-3 standard so that there are
no misunderstandings.

BR Colin.

p.s. not quite sure what question your 13 is answering! :-)

Original Message
From: Theofanis Vassiliou-Gioles_Internet
Sent: 26 July 2002 13:05
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Change Requests on PTCC website


Dear Claude,

>
> Even from this example it is not clear whether you have two rows of
> three columns
> or 2 columns of three rows, i.e. [row] [column] or [column] [row]
What is it good for?

>
> e.g. 1, 2, 3 or 1 11
> 11, 12, 13 2 12
> 3 13
>
> Even if you think it is not needed, I think a clarification would not
> hurt. Comments?
Hmmmm. Although I always favour clarification it is unclear to me, WHAT
should WHY clarified.

> My thought on this is that if we make the storage representation clear
> to everyone,
> the likelihood that two different tool manufacturers interpret this
> differently becomes 0.
Is there a discussion what
myVar[1][2]
(in your example) returns?

I would assume 13

Best regards,

Theo


>
>>
>> BR Colin.
>>
>> p.s. the first point should be clear from the standard the second
>> needs to be clarified explicitly
>
>
>

Please Log in to join the conversation.

Change Requests on PTCC website 26 Jul 2002 12:20 #6171

Hi,
See below.

Best Regards, György

> dr György RÉTHY
> Line Manager
> Ericsson Hungary
> Address: H-1037 Budapest, Laborc street 1.
> Phone: + 36 (1) 437-7006
> Mobile: + 36 (30) 297-7862
> Fax: + 36 (1) 437-7767
> Mail-to: This email address is being protected from spambots. You need JavaScript enabled to view it.


>
Original Message
>From: Theofanis Vassiliou-Gioles [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Friday, July 26, 2002 1:05 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Change Requests on PTCC website
>
>
>Dear Claude,
>
>>
>> Even from this example it is not clear whether you have two rows of
>> three columns
>> or 2 columns of three rows, i.e. [row] [column] or
>[column] [row]
>What is it good for?
>
>>
>> e.g. 1, 2, 3 or 1 11
>> 11, 12, 13 2 12
>> 3 13
>>
>> Even if you think it is not needed, I think a clarification would not
>> hurt. Comments?
>Hmmmm. Although I always favour clarification it is unclear to me, WHAT
>should WHY clarified.
>
>> My thought on this is that if we make the storage
>representation clear
>> to everyone,
>> the likelihood that two different tool manufacturers interpret this
>> differently becomes 0.
>Is there a discussion what
> myVar[1][2]
>(in your example) returns?
>
>I would assume 13

I agree with Theo with a slight addition:
v_Myvar := myVar[1][2];
is not a question.

The question is \
v_MyVar := myVar [0][1];

it may return 2 (if there was myVar [0][1] := 2; before)
or may return 11 (if there was myVar [0][1] := 11; before).

But I think the representation of the a mutidimensional array is an issue that is well above the standard.

BR,György

>
>Best regards,
>
>Theo
>
>
>>
>>>
>>> BR Colin.
>>>
>>> p.s. the first point should be clear from the standard the second
>>> needs to be clarified explicitly
>>
>>
>>
>

Please Log in to join the conversation.

Change Requests on PTCC website 26 Jul 2002 19:00 #6172

In einer eMail vom 7/26/02 1:03:51 PM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


> Dear Claude,
>

Hi Theo,


> >
> > Even from this example it is not clear whether you have two rows of
> > three columns
> > or 2 columns of three rows, i.e. [row] [column] or [column] [row]
> What is it good for?
>

Clarifies how initialization should be done.

> >
> > e.g. 1, 2, 3 or 1 11
> > 11, 12, 13 2 12
> > 3 13
> >
> > Even if you think it is not needed, I think a clarification would not
> > hurt. Comments?
> Hmmmm. Although I always favour clarification it is unclear to me, WHAT
> should WHY clarified.
>

What should be clarified and why? The what is whether row or column major
storage/
initialization should be assumed. Whether this is necessary or not I may not
have
thought through thoroughly, apart from the 'gut feeling' that it may be
better to
clarify things than to leave them open.



> > My thought on this is that if we make the storage representation clear
> > to everyone,
> > the likelihood that two different tool manufacturers interpret this
> > differently becomes 0.
> Is there a discussion what
> myVar[1][2]
> (in your example) returns?
>

Nope,

> I would assume 13
>

In both cases row-column and column-row 13 is the same. Humm,

row 1 column 2 with start index 0,0 gives 13
column 1 row 2 also gives 13.

Ooppsss, a 'faux pas' :-).


> Best regards,
>
> Theo
>
>

Cheers,


Claude.

Please Log in to join the conversation.

  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin