Hello, I'll just post it here, then.

I have two issues with the CR 2757.

1) The first is rather editorial: The examples and synopsises in the
text are not in sync with the proposed solution in the BNF.

2) I don't like the fact that there is another syntax introduced for
something which is very similar to something which already
exists (as Ina already pointed out and Gyorgy agreed, as far as I can
gather from the comments in the CR), namely the param assignment for
getcall/getreply events.

To avoid future confusion in the language, the new value assignment
should follow the same basic syntactic principles. Things which are
alike, should look alike.

Therefore, I propose the following syntax for ValueSpec.

ValueSpec ::= ValueKeyword ( VariableRef |
[VariableRef] "(" {_
VariableRef AssignmentChar (FieldReference | TypeDefIdentifier )
ExtendedFieldReference__ _ _ <#TPortRedirectSymbol>__
<#TVariableRef>_[_"," <#TSemiColon>_] } ")" )

This way, it is possible to assign the whole value to a variable (with
the same syntax as before), if so desired, and additionally fields of
the value to other variables, or, of course, only partial assignments,
if no full assignment should take place.

It is not necessary to switch from one syntax to a different syntax if a
partial assignment should be added to a full assignment later on, i.e. I
don't have to change

-> value v

to

-> value (-> v, f -> vf),

but only to

-> value v (vf := f).

The only drawback that I can see is that it is not possible to do a full
assignment to more than one variable, but since that can be achieved by
later assignment from one to the other variable, as well, I don't see
the advantage.

The other way to avoid the syntax-difference would be to change the
param-assignment syntax, but this would lead to
backwards-incompatibility problems which should be avoided, as well.

Best regards,

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Jacob,

thanks for pointing these issues out:
1)
you are right, there are errors in Example2 of clause 22.2.2:
MyPort.receive(MyType:?) -> value {( MyType -> MyVar;, MyType.messageId -> MyMessageIdVar })

// The value of the received message is stored in the variable

// MyVar and the value of the messageId field of the received

// message is stored in the variable MyMessageIdVar.



MyPort.receive(anytype:?) -> value {( anytype.integer -> MyIntegerVar })

// If the received value is an integer, it is stored in the variable

// MyIntegerVar, a test case error otherwise.



MyPort.receive(charstring:?) -> value {( charstring -> MyCharstringVar })

// The received value is stored in the variable MyCharstringVar;

// Note that it is the same as to write "value MyCharstringVar"



There's a strange mixture of curly brackets and parentheses, in all examples there are superfluous type identifiers, and there's a superfluous semicolon in the first example.

This should be:



MyPort.receive(MyType:?) -> value ( -> MyVar, messageId -> MyMessageIdVar )

// The value of the received message is stored in the variable

// MyVar and the value of the messageId field of the received

// message is stored in the variable MyMessageIdVar.



MyPort.receive(anytype:?) -> value ( integer -> MyIntegerVar )

// If the received value is an integer, it is stored in the variable

// MyIntegerVar, a test case error otherwise.



MyPort.receive(charstring:?) -> value ( -> MyCharstringVar )

// The received value is stored in the variable MyCharstringVar;

// Note that it is the same as to write "value MyCharstringVar"



Please let us know if you are aware of further issues.



2) Regarding the mixture of notations. In general I agree with you, but I have to say that I am not sure whether reusing the notation from parameter redirection would improve the situation. In this case the notations for value redirection of the complete message and for value redirection of message fields would be different. Therefore I think your proposal would not resolve the situation, but I would not object it either.



best regards



Thomas






________________________________

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 Jacob Wieland
Sent: Wednesday, 07. January 2009 13:24
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: CR 2757


Hello, I'll just post it here, then.

I have two issues with the CR 2757.

1) The first is rather editorial: The examples and synopsises in the text are not in sync with the proposed solution in the BNF.

2) I don't like the fact that there is another syntax introduced for something which is very similar to something which already
exists (as Ina already pointed out and Gyorgy agreed, as far as I can gather from the comments in the CR), namely the param assignment for getcall/getreply events.

To avoid future confusion in the language, the new value assignment should follow the same basic syntactic principles. Things which are alike, should look alike.

Therefore, I propose the following syntax for ValueSpec.


ValueSpec ::= ValueKeyword ( VariableRef |
[VariableRef] "(" { VariableRef AssignmentChar (FieldReference | TypeDefIdentifier ) ExtendedFieldReference [","] } ")" )

This way, it is possible to assign the whole value to a variable (with the same syntax as before), if so desired, and additionally fields of the value to other variables, or, of course, only partial assignments, if no full assignment should take place.

It is not necessary to switch from one syntax to a different syntax if a partial assignment should be added to a full assignment later on, i.e. I don't have to change

-> value v

to

-> value (-> v, f -> vf),

but only to

-> value v (vf := f).

The only drawback that I can see is that it is not possible to do a full assignment to more than one variable, but since that can be achieved by later assignment from one to the other variable, as well, I don't see the advantage.

The other way to avoid the syntax-difference would be to change the param-assignment syntax, but this would lead to backwards-incompatibility problems which should be avoided, as well.

Best regards,

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Thomas,

thanks for the feedback. My answer inline.

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
>
> 2) Regarding the mixture of notations. In general I agree with you,
> but I have to say that I am not sure whether reusing the notation from
> parameter redirection would improve the situation. In this case the
> notations for value redirection of the complete message and for value
> redirection of message fields would be different. Therefore I think
> your proposal would not resolve the situation, but I would not object
> it either.
>
>
Yes, complete and partial redirection would be different, but not in a
bad way, in my opinon.

The param-like-syntax would only be used for the new feature of partial
redirection while the full-assignment feature (which already existed)
would work the same way as ever. Thus, the users would only have to
become accustomed to the fact that the same thing that already exists
for getcall/getreply now also works for receive/trigger with (almost)
the same syntax (missing the param keyword).

BR, Jacob
>
> best regards
>
>
>
> Thomas
>
>
>
>
>
>
>

---

> *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 Jacob Wieland
> *Sent:* Wednesday, 07. January 2009 13:24
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* CR 2757
>
> Hello, I'll just post it here, then.
>
> I have two issues with the CR 2757.
>
> 1) The first is rather editorial: The examples and synopsises in
> the text are not in sync with the proposed solution in the BNF.
>
> 2) I don't like the fact that there is another syntax introduced
> for something which is very similar to something which already
> exists (as Ina already pointed out and Gyorgy agreed, as far as I
> can gather from the comments in the CR), namely the param
> assignment for getcall/getreply events.
>
> To avoid future confusion in the language, the new value
> assignment should follow the same basic syntactic principles.
> Things which are alike, should look alike.
>
> Therefore, I propose the following syntax for ValueSpec.
>
> ValueSpec ::= ValueKeyword ( VariableRef |
> [VariableRef]
> "(" {_ VariableRef AssignmentChar (FieldReference |
> TypeDefIdentifier ) ExtendedFieldReference__ __
> <#TPortRedirectSymbol>__ <#TVariableRef>_[_"," <#TSemiColon>_] } ")" )
>
> This way, it is possible to assign the whole value to a variable
> (with the same syntax as before), if so desired, and additionally
> fields of the value to other variables, or, of course, only
> partial assignments, if no full assignment should take place.
>
> It is not necessary to switch from one syntax to a different
> syntax if a partial assignment should be added to a full
> assignment later on, i.e. I don't have to change
>
> -> value v
>
> to
>
> -> value (-> v, f -> vf),
>
> but only to
>
> -> value v (vf := f).
>
> The only drawback that I can see is that it is not possible to do
> a full assignment to more than one variable, but since that can be
> achieved by later assignment from one to the other variable, as
> well, I don't see the advantage.
>
> The other way to avoid the syntax-difference would be to change
> the param-assignment syntax, but this would lead to
> backwards-incompatibility problems which should be avoided, as well.
>
> Best regards,
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> UPCOMING EVENTS
>
> January 14, Free TTCN-3 Webinar
> TTCN-3 for Test Automation
> www.testingtech.com/services/ttcn3_webinar.php
>
> January 26-28, 2009, TTCN-3 Tutorial
> Accredited TTCN-3 Certification Course
> www.testingtech.com/services/ttcn3_tutorial.php
>
> February 16-19, 2009, Mobile World Congress
> Barcelona, Spain, Hall 2.1, Booth #B77
> www.mobileworldcongress.com/
>
>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi,

I would prefer to clearly differentiate single and multiple storing, i.e. with the bracket following "value" directly. We should look at more realistic cases than the simple examples, e.g. something like:
RRC.receive (c_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(myParam2, MyParam2) ) -> value v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(v_ptmsi := v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6.asn1_message.rrcConnectionRequest.initialUE_Identity.p_TMSI_and-RAI.p-TMSI)

In this case the fact that more fields are saved can easily be overlooked as expending to the next line(s) without any sign in the line with the receive. So, I would rather prefer the syntax like:

RRC.receive (c_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(myParam2, MyParam2) ) -> value (v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6, v_ptmsi := v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6.asn1_message.rrcConnectionRequest.initialUE_Identity.p_TMSI_and-RAI.p-TMSI)

Do we use "->" or ":=" within the brackets is not so important to me. If one wants to outcomment the field storing during debugging, I think that add/delete the opening bracket is not so difficult.

BR, Gyorgy


________________________________

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 Jacob Wieland
Sent: 2009-január-8 14:41
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: CR 2757


Hello Thomas,

thanks for the feedback. My answer inline.

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:




2) Regarding the mixture of notations. In general I agree with you,
but I have to say that I am not sure whether reusing the notation from parameter redirection would improve the situation. In this case the notations for value redirection of the complete message and for value redirection of message fields would be different. Therefore I think your proposal would not resolve the situation, but I would not object it either.




Yes, complete and partial redirection would be different, but not in a bad way, in my opinon.

The param-like-syntax would only be used for the new feature of partial redirection while the full-assignment feature (which already existed) would work the same way as ever. Thus, the users would only have to become accustomed to the fact that the same thing that already exists for getcall/getreply now also works for receive/trigger with (almost) the same syntax (missing the param keyword).

BR, Jacob


best regards



Thomas






________________________________

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 Jacob Wieland
Sent: Wednesday, 07. January 2009 13:24
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: CR 2757


Hello, I'll just post it here, then.

I have two issues with the CR 2757.

1) The first is rather editorial: The examples and synopsises
in the text are not in sync with the proposed solution in the BNF.

2) I don't like the fact that there is another syntax
introduced for something which is very similar to something which already
exists (as Ina already pointed out and Gyorgy agreed, as far
as I can gather from the comments in the CR), namely the param assignment for getcall/getreply events.

To avoid future confusion in the language, the new value
assignment should follow the same basic syntactic principles. Things which are alike, should look alike.

Therefore, I propose the following syntax for ValueSpec.


ValueSpec ::= ValueKeyword ( VariableRef |

[VariableRef] "(" { VariableRef AssignmentChar (FieldReference | TypeDefIdentifier ) ExtendedFieldReference [","] } ")" )

This way, it is possible to assign the whole value to a
variable (with the same syntax as before), if so desired, and additionally fields of the value to other variables, or, of course, only partial assignments, if no full assignment should take place.

It is not necessary to switch from one syntax to a different
syntax if a partial assignment should be added to a full assignment later on, i.e. I don't have to change

-> value v

to

-> value (-> v, f -> vf),

but only to

-> value v (vf := f).

The only drawback that I can see is that it is not possible to
do a full assignment to more than one variable, but since that can be achieved by later assignment from one to the other variable, as well, I don't see the advantage.

The other way to avoid the syntax-difference would be to
change the param-assignment syntax, but this would lead to backwards-incompatibility problems which should be avoided, as well.

Best regards,

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan
Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material
for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are not
the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this
message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Gyorgy,

that's a compromise I could live with.

BR, Jacob

György Réthy wrote:
> Hi,
>
> I would prefer to clearly differentiate single and multiple storing,
> i.e. with the bracket following "value" directly. We should look at
> more realistic cases than the simple examples, e.g. something like:
>
> RRC.receive
> (c_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(myParam2,
> MyParam2) ) -> value
> v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(v_ptmsi :=
> v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6.asn1_message.rrcConnectionRequest.initialUE_Identity.p_TMSI_and-RAI.p-TMSI)
>
> In this case the fact that more fields are saved can easily be
> overlooked as expending to the next line(s) without any sign in the
> line with the receive. So, I would rather prefer the syntax like:
>
> RRC.receive
> (c_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(myParam2,
> MyParam2) ) ->
> value (v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6, v_ptmsi
> :=
> v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6.asn1_message.rrcConnectionRequest.initialUE_Identity.p_TMSI_and-RAI.p-TMSI)
>
> Do we use "->" or ":=" within the brackets is not so important to me.
> If one wants to outcomment the field storing during debugging, I think
> that add/delete the opening bracket is not so difficult.
>
> BR, Gyorgy
>
>

---

> *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 *Jacob Wieland
> *Sent:* 2009-január-8 14:41
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: CR 2757
>
> Hello Thomas,
>
> thanks for the feedback. My answer inline.
>
> Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
>>
>> 2) Regarding the mixture of notations. In general I agree with
>> you, but I have to say that I am not sure whether reusing the
>> notation from parameter redirection would improve the situation.
>> In this case the notations for value redirection of the complete
>> message and for value redirection of message fields would be
>> different. Therefore I think your proposal would not resolve the
>> situation, but I would not object it either.
>>
>>
> Yes, complete and partial redirection would be different, but not
> in a bad way, in my opinon.
>
> The param-like-syntax would only be used for the new feature of
> partial redirection while the full-assignment feature (which
> already existed) would work the same way as ever. Thus, the users
> would only have to become accustomed to the fact that the same
> thing that already exists for getcall/getreply now also works for
> receive/trigger with (almost) the same syntax (missing the param
> keyword).
>
> BR, Jacob
>>
>> best regards
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>

---

>> *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
>> Jacob Wieland
>> *Sent:* Wednesday, 07. January 2009 13:24
>> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
>> *Subject:* CR 2757
>>
>> Hello, I'll just post it here, then.
>>
>> I have two issues with the CR 2757.
>>
>> 1) The first is rather editorial: The examples and synopsises
>> in the text are not in sync with the proposed solution in the
>> BNF.
>>
>> 2) I don't like the fact that there is another syntax
>> introduced for something which is very similar to something
>> which already
>> exists (as Ina already pointed out and Gyorgy agreed, as far
>> as I can gather from the comments in the CR), namely the
>> param assignment for getcall/getreply events.
>>
>> To avoid future confusion in the language, the new value
>> assignment should follow the same basic syntactic principles.
>> Things which are alike, should look alike.
>>
>> Therefore, I propose the following syntax for ValueSpec.
>>
>> ValueSpec ::= ValueKeyword ( VariableRef |
>>
>> [VariableRef] "(" {_ VariableRef AssignmentChar
>> (FieldReference | TypeDefIdentifier )
>> ExtendedFieldReference__ __ <#TPortRedirectSymbol>__
>> <#TVariableRef>_[_"," <#TSemiColon>_] } ")" )
>>
>> This way, it is possible to assign the whole value to a
>> variable (with the same syntax as before), if so desired, and
>> additionally fields of the value to other variables, or, of
>> course, only partial assignments, if no full assignment
>> should take place.
>>
>> It is not necessary to switch from one syntax to a different
>> syntax if a partial assignment should be added to a full
>> assignment later on, i.e. I don't have to change
>>
>> -> value v
>>
>> to
>>
>> -> value (-> v, f -> vf),
>>
>> but only to
>>
>> -> value v (vf := f).
>>
>> The only drawback that I can see is that it is not possible
>> to do a full assignment to more than one variable, but since
>> that can be achieved by later assignment from one to the
>> other variable, as well, I don't see the advantage.
>>
>> The other way to avoid the syntax-difference would be to
>> change the param-assignment syntax, but this would lead to
>> backwards-incompatibility problems which should be avoided,
>> as well.
>>
>> Best regards,
>>
>> --
>>

---

>> Jacob Wieland
>> Software Engineer
>>
>> Testing Technologies IST GmbH
>> Michaelkirchstraße 17/18
>> 10179 Berlin, Germany
>>
>> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>>

---

>>
>> UPCOMING EVENTS
>>
>> January 14, Free TTCN-3 Webinar
>> TTCN-3 for Test Automation
>> www.testingtech.com/services/ttcn3_webinar.php
>>
>> January 26-28, 2009, TTCN-3 Tutorial
>> Accredited TTCN-3 Certification Course
>> www.testingtech.com/services/ttcn3_tutorial.php
>>
>> February 16-19, 2009, Mobile World Congress
>> Barcelona, Spain, Hall 2.1, Booth #B77
>> www.mobileworldcongress.com/
>>
>>

---

>> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
>> Handelsregister HRB 77805, Amtsgericht Charlottenburg
>> Ust ID Nr.: DE 813 143 070
>>
>> This e-mail may contain confidential and privileged material for the
>> sole use of the intended recipient. Any review, use, distribution or
>> disclosure by others is strictly prohibited. If you are not the intended
>> recipient (or authorized to receive for the recipient), please contact
>> the sender by reply e-mail and delete all copies of this message.
>>
>>
>
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> UPCOMING EVENTS
>
> January 14, Free TTCN-3 Webinar
> TTCN-3 for Test Automation
> www.testingtech.com/services/ttcn3_webinar.php
>
> January 26-28, 2009, TTCN-3 Tutorial
> Accredited TTCN-3 Certification Course
> www.testingtech.com/services/ttcn3_tutorial.php
>
> February 16-19, 2009, Mobile World Congress
> Barcelona, Spain, Hall 2.1, Booth #B77
> www.mobileworldcongress.com/
>
>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Jacob and Gyorgy,

would also be ok from my side.

best regards

Thomas



________________________________

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 Jacob Wieland
Sent: Friday, 09. January 2009 10:19
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: CR 2757


Hello Gyorgy,

that's a compromise I could live with.

BR, Jacob

György Réthy wrote:

Hi,

I would prefer to clearly differentiate single and multiple storing,
i.e. with the bracket following "value" directly. We should look at more realistic cases than the simple examples, e.g. something like:
RRC.receive (c_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(myParam2, MyParam2) ) -> value v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(v_ptmsi := v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6.asn1_message.rrcConnectionRequest.initialUE_Identity.p_TMSI_and-RAI.p-TMSI)

In this case the fact that more fields are saved can easily be overlooked as expending to the next line(s) without any sign in the line with the receive. So, I would rather prefer the syntax like:

RRC.receive (c_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6(myParam2, MyParam2) ) -> value (v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6, v_ptmsi := v_RRC_ConnReqRACH_IntraFrequencyReportingQuantity_r6.asn1_message.rrcConnectionRequest.initialUE_Identity.p_TMSI_and-RAI.p-TMSI)

Do we use "->" or ":=" within the brackets is not so important to
me. If one wants to outcomment the field storing during debugging, I think that add/delete the opening bracket is not so difficult.

BR, Gyorgy


________________________________

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 Jacob Wieland
Sent: 2009-január-8 14:41
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: CR 2757


Hello Thomas,

thanks for the feedback. My answer inline.

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:




2) Regarding the mixture of notations. In general I
agree with you, but I have to say that I am not sure whether reusing the notation from parameter redirection would improve the situation. In this case the notations for value redirection of the complete message and for value redirection of message fields would be different. Therefore I think your proposal would not resolve the situation, but I would not object it either.




Yes, complete and partial redirection would be different, but
not in a bad way, in my opinon.

The param-like-syntax would only be used for the new feature
of partial redirection while the full-assignment feature (which already existed) would work the same way as ever. Thus, the users would only have to become accustomed to the fact that the same thing that already exists for getcall/getreply now also works for receive/trigger with (almost) the same syntax (missing the param keyword).

BR, Jacob


best regards



Thomas






________________________________

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 Jacob Wieland
Sent: Wednesday, 07. January 2009 13:24
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: CR 2757


Hello, I'll just post it here, then.

I have two issues with the CR 2757.

1) The first is rather editorial: The examples and
synopsises in the text are not in sync with the proposed solution in the BNF.

2) I don't like the fact that there is another
syntax introduced for something which is very similar to something which already
exists (as Ina already pointed out and Gyorgy
agreed, as far as I can gather from the comments in the CR), namely the param assignment for getcall/getreply events.

To avoid future confusion in the language, the new
value assignment should follow the same basic syntactic principles. Things which are alike, should look alike.

Therefore, I propose the following syntax for
ValueSpec.


ValueSpec ::= ValueKeyword ( VariableRef |

[VariableRef] "(" { VariableRef AssignmentChar (FieldReference | TypeDefIdentifier ) ExtendedFieldReference [","] } ")" )

This way, it is possible to assign the whole value
to a variable (with the same syntax as before), if so desired, and additionally fields of the value to other variables, or, of course, only partial assignments, if no full assignment should take place.

It is not necessary to switch from one syntax to a
different syntax if a partial assignment should be added to a full assignment later on, i.e. I don't have to change

-> value v

to

-> value (-> v, f -> vf),

but only to

-> value v (vf := f).

The only drawback that I can see is that it is not
possible to do a full assignment to more than one variable, but since that can be achieved by later assignment from one to the other variable, as well, I don't see the advantage.

The other way to avoid the syntax-difference would
be to change the param-assignment syntax, but this would lead to backwards-incompatibility problems which should be avoided, as well.

Best regards,

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles,
Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht
Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and
privileged material for the
sole use of the intended recipient. Any review,
use, distribution or
disclosure by others is strictly prohibited. If
you are not the intended
recipient (or authorized to receive for the
recipient), please contact
the sender by reply e-mail and delete all copies
of this message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan
Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material
for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are not
the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this
message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

January 14, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

January 26-28, 2009, TTCN-3 Tutorial
Accredited TTCN-3 Certification Course
www.testingtech.com/services/ttcn3_tutorial.php

February 16-19, 2009, Mobile World Congress
Barcelona, Spain, Hall 2.1, Booth #B77
www.mobileworldcongress.com/

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.