Hi all,

Can anybody help me, where to find a document describing technical problems identified by STF 187 (or accepted by the the STF from the mailing list as a real problem in the framework of the current standard version)? I can find just some proposals to change the standards text (I mean Anthony's mail from 19/July) but no background.

Best Regards, György

============================================
dr. György RÉTHY
Ericsson Communications Systems Hungary Lim.
Conformance Center
tel.: +36 1 437-7006; fax: +36 1 437-7767
mobile: +36 30 297-7862
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
web: www.r.eth.ericsson.se/~ethgry
============================================


>

---

Original Message

---

>From: Csaba Koppany [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Monday, August 27, 2001 10:53 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: "goto alt" and "repeat"
>
>
>Hi Jens,
>
>here is the ToR of the STF:
>www.etsi.org/stfs/News/ToR/tor187.doc
>
>"... The TTCN-3 validation process and the co-operation with users and
>toolmakers in the early part of 2000 has proved very useful in
>removing as many
>errors and ambiguities as possible. However, with a project of
>this complexity
>it is inevitable that some (minor) inconsistencies remain. It
>will be the task
>of the STF to collect error reports from the user and
>implementers community
>and, where necessary, to correct the standard accordingly. The
>STF shall not add
>new functionality to TTCN-3."
>
>1. I have no problem with including regular expressions, even
>it is not in the
>ToR, but it seems that ToR shall be modified.
>
>2. I have problems with backward compatibilty. Acc. to the
>published version of
>TTCNv3 "goto alt" shall be used in some of the situations. If
>someone use "goto
>alt" will cause syntax error acc. to the TTCNv3 editon 2. That
>is my problem. As
>I know there were a discussion about the name of this keyword,
>and decision was
>done to use "goto alt" instead of "repeat" was mentioned earlier as an
>alternative. Maybe it was not the best, but a decision so I
>think we shall be
>consequesce. I do not know now that the "repeat" will be used
>only in default or
>in normal alternatives as well. I have no objections
>correctiong errors and
>introducing new keywords if neccessary, but I would keep "goto
>alt" and do not
>delete from the standard.
>
>3. I have the same problem with removing "expand" and
>replacing "named alt" with
>testsep. It is not oly the chenge of the name, but has
>different functionality.
>OK. But why to delete named alt and expand?
>
>There is a released version of TTCNv3 with some conceptual
>(good or bad)
>decisions, but I think the correction of these unclarified
>situations and
>problems can be solved without changing the bnf.
>
>BR, Csaba.
>
>> X-Accept-Language: de,en
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 8bit
>> X-Virus-Scanned: by AMaViS perl-11
>> Date: Sat, 25 Aug 2001 17:39:21 +0200
>> From: Jens Grabowski <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>> Subject: Re: "goto alt" and "repeat"
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>
>> This discussion is going into the wrong direction:
>>
>> STF 187 has of course only a mandate for the maintenance and error
>> correction of the last TTCN-3 document and not to introduce
>> new things. (I cannot find the ToR for STF 187 therefore I hope this
>> formulation is 'politically' correct.)
>>
>> The only exception to this mandate are the regular
>expressions. This has
>> been explained by Anthony in a mail to this list on the 20th of March
>> with
>> the subject: Status report
>>
>> > The maintenance work will begin on week 19 with 2
>man-months of resource
>> > spread over the year. One technical task that will be done
>immediately is to
>> > introduce regular expressions into TTCN-3. This is
>urgently needed for
>> > testing text-based (IP)protocols such as SIP. All
>contributions to this
>> > activity will be welcome.
>>
>> (Again, I cannot find the ToR and I cannot remember if the
>inclusion of
>> regular expressions into TTCN-3 is mentioned in the ToR.)
>>
>> The work on the
>> - defaults mechanism,
>> - import mechanism and
>> - non-blocking procedures
>> is considered to be error corrections and have been discussed in this
>> email list.
>>
>> All work on the text (removal of typos, correction of
>examples, removal
>> of ambiguities,
>> improvement of readability, small BNF corrections, etc.) is
>considered
>> to be maintenance
>> work. Most of these textual problems have also been discussed in this
>> email list.
>>
>> For preparing some of the proposals that have been send out
>by Anthony
>> to this list,
>> at least I asked some members of the email list on a personal basis,
>> e.g., Jacob has
>> contributed a lot to the defaults proposal. However, the results of
>> these discussions
>> have been send out by Anthony in form of the proposals. There is no
>> hidden personal
>> discussion which change the standard.
>>
>> To my knowledge the issues to work on were based on input either sent
>> directly to
>> Anthony or into this group, e.g., the comments from Olivier
>Dubuisson on
>> regular
>> expressions that has been sent to this group, will be
>discussed at the
>> beginning
>> of the next STF 187 work session in October. (Maybe this is a
>> non-tranparent part,
>> because you do not see the inputs sent directly to Anthony.
>Furthermore,
>> we make a
>> list of all received items at the beginning of each work session and
>> assign priorities
>> to these items. Then we work according to these priorities. Of course
>> different
>> persons would assign the priorities in a different manner.)
>>
>> New language features, e.g., a TTCN-3 counterpart for the
>'any' type of
>> IDL,
>> have only been discussed on a personal level and I don't know how the
>> official
>> procedure for bigger changes in the TTCN-3 standard is.
>>
>> That's all.
>>
>> Best regards
>>
>> Jens
>>
>> Please note: This email reflects my personal opinion and
>> is not an official statement of my employer or STF 187.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> "I. Schieferdecker" schrieb:
>> >
>> > Hi Jens,
>> >
>> > > Hi,
>> > >
>> > > - sorry, I forgot the regular expressions because I only
>looked through
>> > > the main text and not through the annexes. The proposal for the
>> > > regular
>> > > expressions is related to Annex B.
>> > >
>> > > - The other things (ranges and any type) are at the
>moment on the level
>> > > of personal discussions among us (at least I thought
>they are!).
>> >
>> > also many other things have been on the level of personal
>discussion (e.g.
>> > defaults to name only one). So, how does a thing become an
>official one?
>> >
>> > Again just for clarification, because we have also some
>concerns what goes
>> > into TTCN-3 and what does not.
>> >
>> > Thanks and have a nice weekend,
>> >
>> > Ina.
>> >
>> > >
>> > > - About a list of open issues you have to ask Anthony, I
>think he has
>> > > such
>> > > a list.
>> > >
>> > > Best regards
>> > > Jens
>> > >
>> > >
>> > >
>> > > "I. Schieferdecker" schrieb:
>> > > >
>> > > > Dear Jens,
>> > > >
>> > > > I understood that also regular expressions, i.e. a
>real extension, will
>become
>> > > > part of the "Oct. version"?!
>> > > >
>> > > > And, what is with the other two points we are discussing:
>> > > > - Ranges for Float
>> > > > - any type (to have an analogon for TTCN-2 PDU and for
>the CORBA IDL any
>type)
>> > > >
>> > > > In fact, is there an open issues list for TTCN-3?
>> > > >
>> > > > Thanks in advance for the clarification.
>> > > >
>> > > > With best regards,
>> > > >
>> > > > Ina.
>> > > >
>> > > > > Dear Csaba,
>> > > > >
>> > > > > The proposed change of 'goto alt' into 'repeat' is due to
>> > > > > corrections related to the default behaviour. The macro
>> > > > > expansion mechanism has some problems and fixing
>these problems,
>> > > > > i.e., defining several exceptions which would be difficult to
>> > > > > implement, would cause more problems than proposing
>a clean and
>> > > > > backwards compatible default mechanism.
>> > > > >
>> > > > > For leaving an activated default and forcing the
>re-evaluation
>> > > > > of the alt-statement in which the default was
>invoked, a special
>> > > > > statement was needed. This statement is not a simple
>goto because
>> > > > > the proposed default mechanism is not based on macro
>expansion.
>> > > > > We think that the keyword 'repeat' would be perfect
>to express
>> > > > > this fact.
>> > > > >
>> > > > > We also detected that 'goto alt' has somehow the same
>> > > > > functionality and therefore we found it natural to
>propose the
>> > > > > replacement of 'goto alt' by 'repeat'. That's all.
>> > > > >
>> > > > > However, from your mail I got the impression that
>you have the
>> > > > > feeling we introduced new things instead of making correctios
>> > > > > and keeping the standard stable.
>> > > > >
>> > > > > This might be influenced by the number of different
>discussions
>> > > > > in this email list, but I believe this is not true.
>> > > > > I try to summarize the proposed corrections and changes.
>> > > > >
>> > > > > The following things have been proposed:
>> > > > >
>> > > > > 1) Correction of ambiguities and problems with the
>import mechanism.
>> > > > >
>> > > > > Effects: - Changes in the textual description
>> > > > > - One syntax option which is related to
>the import
>> > > > > of language constructs that use module
>parameter.
>> > > > >
>> > > > > 2) Removing an ambiguity for blocking and non-blocking
>> > > > > procedure-based communication.
>> > > > >
>> > > > > Effects: - one optional keyword 'noblock'
>> > > > > - Additions in the textual description.
>> > > > >
>> > > > >
>> > > > > 3) Correction of the default mechanism, i.e., replacing the
>macro-based
>> > > > > default mechanism by a more user-friendly
>function-oriented default
>> > > > > mechanism.
>> > > > >
>> > > > > Effects: - Changes of the textual description of
>the default
>> > > > > mechanism.
>> > > > >
>> > > > > - Replacement of 'named alt' by 'teststep'
>> > > > > - Replacement of 'goto alt' by 'repeat'
>> > > > > - Removal of the 'expand' keyword.
>> > > > > - Introduction of a 'default' handle
>> > > > >
>> > > > > (The 'default' was introduced to solve
>the older and known
>> > > > > problem of multiple activation of the
>same default with
>> > > > > different
>> > > > > actual parameters.)
>> > > > >
>> > > > >
>> > > > > In addition there are requests for clearifying text
>about existing
>> > > > > restrictions
>> > > > > on 'map' and 'connect' operations and timers.
>Furthermore, the
>structure
>> > > > > of
>> > > > > presenting the communication operations may be
>improved, a section on
>> > > > > type
>> > > > > compatability has been proposed and the terminology
>of synchronous and
>> > > > > asynchronous
>> > > > > communications should be changed to procedure-based
>and message-based
>> > > > > communication.
>> > > > >
>> > > > > If you count, you find three reasons for small
>syntax changes (import,
>> > > > > 'noblock',
>> > > > > default handle) and three cosmetic corrections
>('teststep', 'repeat',
>> > > > > 'expand').
>> > > > >
>> > > > > Just a small remark to the cosmetic corrections: we
>felt that the
>> > > > > semantic changes
>> > > > > with respect to defaults should be reflected in the
>keywords. By
>keeping
>> > > > > the old
>> > > > > keywords 'named alt' and 'goto alt', we thought that
>there is the
>danger
>> > > > > to be misleaded
>> > > > > by the old macro-based mechanism.
>> > > > >
>> > > > > I hope this convinces you that we really tried to
>propose small
>> > > > > syntactic changes only
>> > > > > and put a lot of effort into removing ambiguities
>from and improving
>the
>> > > > > readability of
>> > > > > the textual description of TTCN-3.
>> > > > >
>> > > > > (Btw. I often use the term 'we'. With 'we' I do not
>mean Anthony,
>Colin
>> > > > > and myself only,
>> > > > > but also all the people of this email list that
>helped to find,
>discuss
>> > > > > and resolve
>> > > > > ambiguities in the standard and/or made
>contributions to sections of
>the
>> > > > > standard.)
>> > > > >
>> > > > > Best regards
>> > > > > Jens
>> > > > >
>> > > > >
>> > > > > Csaba Koppany schrieb:
>> > > > > >
>> > > > > > Hello Jens and others,
>> > > > > >
>> > > > > > you wrote:
>> > > > > > (The goto alt will be replaced by a repeat
>statement in October.)
>> > > > > >
>> > > > > > Can you tell me what is the reason for this
>change. As I see in the
>ToR of STF
>> > > > > > 187 there shall be only minor changes of the core
>in edition 2.
>> > > > > >
>> > > > > > I do not agree modifications, which harms backward
>compatibility and
>change the
>> > > > > > syntax, except major faults in the existing
>language. We need a
>stable TTCNv3
>> > > > > > instead of several versions circulating around.
>> > > > > >
>> > > > > > So give a good reson for such kind of changes (as
>I see this is not
>the only one
>> > > > > > planned.) I am really interested in others opinion
>about that!
>> > > > > >
>> > > > > > Regards,
>> > > > > > Csaba.
>> > > > > > ============================================
>> > > > > > Csaba Koppány
>> > > > > > Ericsson Communications Systems Hungary Lim.
>> > > > > > tel: +36 1 437-7930; fax: +36 1 437-7767
>> > > > > > e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > > > > > ============================================
>> > > > >
>> > > > > --
>> > > > >
>> > > > >
>======================================================================
>> > > > > Dr. Jens Grabowski
>> > > > > Institute for Telematics phone: +49 451 500 3723
>> > > > > University of Luebeck fax: +49 451 500 3722
>> > > > > Ratzeburger Allee 160 eMail:
>This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > > > > D-23538 Luebeck or
>This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > > > > (Germany) WWW:
>www.itm.mu-luebeck.de
>> > > > >
>======================================================================
>> > >
>> > > --
>> > >
>> > >
>======================================================================
>> > > Dr. Jens Grabowski
>> > > Institute for Telematics phone: +49 451 500 3723
>> > > University of Luebeck fax: +49 451 500 3722
>> > > Ratzeburger Allee 160 eMail:
>This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
>> > > (Germany) WWW:
>www.itm.mu-luebeck.de
>> > >
>======================================================================
>>
>> --
>>
>>
>======================================================================
>> Dr. Jens Grabowski
>> Institute for Telematics phone: +49 451 500 3723
>> University of Luebeck fax: +49 451 500 3722
>> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
>> (Germany) WWW:
>www.itm.mu-luebeck.de
>>
>======================================================================
>
>============================================
>Csaba Koppány
>Ericsson Communications Systems Hungary Lim.
>tel: +36 1 437-7930; fax: +36 1 437-7767
>e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>============================================
>

There is a list which I will distribute later today or tomorrow (I need to
clarify a couple of points with Jens and Colin first).

Anthony

>

---

Original Message

---

> From: Gyorgy Rethy (ETH) [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 18 September 2001 18:02
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: TTCN-3 changes
>
>
> Hi all,
>
> Can anybody help me, where to find a document describing
> technical problems identified by STF 187 (or accepted by the
> the STF from the mailing list as a real problem in the
> framework of the current standard version)? I can find just
> some proposals to change the standards text (I mean
> Anthony's mail from 19/July) but no background.
>
> Best Regards, György
>
> ============================================
> dr. György RÉTHY
> Ericsson Communications Systems Hungary Lim.
> Conformance Center
> tel.: +36 1 437-7006; fax: +36 1 437-7767
> mobile: +36 30 297-7862
> e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> web: www.r.eth.ericsson.se/~ethgry
> ============================================
>
>
> >

---

Original Message

---

> >From: Csaba Koppany [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >Sent: Monday, August 27, 2001 10:53 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: "goto alt" and "repeat"
> >
> >
> >Hi Jens,
> >
> >here is the ToR of the STF:
> >www.etsi.org/stfs/News/ToR/tor187.doc
> >
> >"... The TTCN-3 validation process and the co-operation with
> users and
> >toolmakers in the early part of 2000 has proved very useful in
> >removing as many
> >errors and ambiguities as possible. However, with a project of
> >this complexity
> >it is inevitable that some (minor) inconsistencies remain. It
> >will be the task
> >of the STF to collect error reports from the user and
> >implementers community
> >and, where necessary, to correct the standard accordingly. The
> >STF shall not add
> >new functionality to TTCN-3."
> >
> >1. I have no problem with including regular expressions, even
> >it is not in the
> >ToR, but it seems that ToR shall be modified.
> >
> >2. I have problems with backward compatibilty. Acc. to the
> >published version of
> >TTCNv3 "goto alt" shall be used in some of the situations. If
> >someone use "goto
> >alt" will cause syntax error acc. to the TTCNv3 editon 2. That
> >is my problem. As
> >I know there were a discussion about the name of this keyword,
> >and decision was
> >done to use "goto alt" instead of "repeat" was mentioned
> earlier as an
> >alternative. Maybe it was not the best, but a decision so I
> >think we shall be
> >consequesce. I do not know now that the "repeat" will be used
> >only in default or
> >in normal alternatives as well. I have no objections
> >correctiong errors and
> >introducing new keywords if neccessary, but I would keep "goto
> >alt" and do not
> >delete from the standard.
> >
> >3. I have the same problem with removing "expand" and
> >replacing "named alt" with
> >testsep. It is not oly the chenge of the name, but has
> >different functionality.
> >OK. But why to delete named alt and expand?
> >
> >There is a released version of TTCNv3 with some conceptual
> >(good or bad)
> >decisions, but I think the correction of these unclarified
> >situations and
> >problems can be solved without changing the bnf.
> >
> >BR, Csaba.
> >
> >> X-Accept-Language: de,en
> >> MIME-Version: 1.0
> >> Content-Transfer-Encoding: 8bit
> >> X-Virus-Scanned: by AMaViS perl-11
> >> Date: Sat, 25 Aug 2001 17:39:21 +0200
> >> From: Jens Grabowski <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> >> Subject: Re: "goto alt" and "repeat"
> >> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >>
> >> This discussion is going into the wrong direction:
> >>
> >> STF 187 has of course only a mandate for the maintenance and error
> >> correction of the last TTCN-3 document and not to introduce
> >> new things. (I cannot find the ToR for STF 187 therefore I
> hope this
> >> formulation is 'politically' correct.)
> >>
> >> The only exception to this mandate are the regular
> >expressions. This has
> >> been explained by Anthony in a mail to this list on the
> 20th of March
> >> with
> >> the subject: Status report
> >>
> >> > The maintenance work will begin on week 19 with 2
> >man-months of resource
> >> > spread over the year. One technical task that will be done
> >immediately is to
> >> > introduce regular expressions into TTCN-3. This is
> >urgently needed for
> >> > testing text-based (IP)protocols such as SIP. All
> >contributions to this
> >> > activity will be welcome.
> >>
> >> (Again, I cannot find the ToR and I cannot remember if the
> >inclusion of
> >> regular expressions into TTCN-3 is mentioned in the ToR.)
> >>
> >> The work on the
> >> - defaults mechanism,
> >> - import mechanism and
> >> - non-blocking procedures
> >> is considered to be error corrections and have been
> discussed in this
> >> email list.
> >>
> >> All work on the text (removal of typos, correction of
> >examples, removal
> >> of ambiguities,
> >> improvement of readability, small BNF corrections, etc.) is
> >considered
> >> to be maintenance
> >> work. Most of these textual problems have also been
> discussed in this
> >> email list.
> >>
> >> For preparing some of the proposals that have been send out
> >by Anthony
> >> to this list,
> >> at least I asked some members of the email list on a
> personal basis,
> >> e.g., Jacob has
> >> contributed a lot to the defaults proposal. However, the results of
> >> these discussions
> >> have been send out by Anthony in form of the proposals. There is no
> >> hidden personal
> >> discussion which change the standard.
> >>
> >> To my knowledge the issues to work on were based on input
> either sent
> >> directly to
> >> Anthony or into this group, e.g., the comments from Olivier
> >Dubuisson on
> >> regular
> >> expressions that has been sent to this group, will be
> >discussed at the
> >> beginning
> >> of the next STF 187 work session in October. (Maybe this is a
> >> non-tranparent part,
> >> because you do not see the inputs sent directly to Anthony.
> >Furthermore,
> >> we make a
> >> list of all received items at the beginning of each work
> session and
> >> assign priorities
> >> to these items. Then we work according to these
> priorities. Of course
> >> different
> >> persons would assign the priorities in a different manner.)
> >>
> >> New language features, e.g., a TTCN-3 counterpart for the
> >'any' type of
> >> IDL,
> >> have only been discussed on a personal level and I don't
> know how the
> >> official
> >> procedure for bigger changes in the TTCN-3 standard is.
> >>
> >> That's all.
> >>
> >> Best regards
> >>
> >> Jens
> >>
> >> Please note: This email reflects my personal opinion and
> >> is not an official statement of my employer
> or STF 187.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> "I. Schieferdecker" schrieb:
> >> >
> >> > Hi Jens,
> >> >
> >> > > Hi,
> >> > >
> >> > > - sorry, I forgot the regular expressions because I only
> >looked through
> >> > > the main text and not through the annexes. The
> proposal for the
> >> > > regular
> >> > > expressions is related to Annex B.
> >> > >
> >> > > - The other things (ranges and any type) are at the
> >moment on the level
> >> > > of personal discussions among us (at least I thought
> >they are!).
> >> >
> >> > also many other things have been on the level of personal
> >discussion (e.g.
> >> > defaults to name only one). So, how does a thing become an
> >official one?
> >> >
> >> > Again just for clarification, because we have also some
> >concerns what goes
> >> > into TTCN-3 and what does not.
> >> >
> >> > Thanks and have a nice weekend,
> >> >
> >> > Ina.
> >> >
> >> > >
> >> > > - About a list of open issues you have to ask Anthony, I
> >think he has
> >> > > such
> >> > > a list.
> >> > >
> >> > > Best regards
> >> > > Jens
> >> > >
> >> > >
> >> > >
> >> > > "I. Schieferdecker" schrieb:
> >> > > >
> >> > > > Dear Jens,
> >> > > >
> >> > > > I understood that also regular expressions, i.e. a
> >real extension, will
> >become
> >> > > > part of the "Oct. version"?!
> >> > > >
> >> > > > And, what is with the other two points we are discussing:
> >> > > > - Ranges for Float
> >> > > > - any type (to have an analogon for TTCN-2 PDU and for
> >the CORBA IDL any
> >type)
> >> > > >
> >> > > > In fact, is there an open issues list for TTCN-3?
> >> > > >
> >> > > > Thanks in advance for the clarification.
> >> > > >
> >> > > > With best regards,
> >> > > >
> >> > > > Ina.
> >> > > >
> >> > > > > Dear Csaba,
> >> > > > >
> >> > > > > The proposed change of 'goto alt' into 'repeat' is due to
> >> > > > > corrections related to the default behaviour. The macro
> >> > > > > expansion mechanism has some problems and fixing
> >these problems,
> >> > > > > i.e., defining several exceptions which would be
> difficult to
> >> > > > > implement, would cause more problems than proposing
> >a clean and
> >> > > > > backwards compatible default mechanism.
> >> > > > >
> >> > > > > For leaving an activated default and forcing the
> >re-evaluation
> >> > > > > of the alt-statement in which the default was
> >invoked, a special
> >> > > > > statement was needed. This statement is not a simple
> >goto because
> >> > > > > the proposed default mechanism is not based on macro
> >expansion.
> >> > > > > We think that the keyword 'repeat' would be perfect
> >to express
> >> > > > > this fact.
> >> > > > >
> >> > > > > We also detected that 'goto alt' has somehow the same
> >> > > > > functionality and therefore we found it natural to
> >propose the
> >> > > > > replacement of 'goto alt' by 'repeat'. That's all.
> >> > > > >
> >> > > > > However, from your mail I got the impression that
> >you have the
> >> > > > > feeling we introduced new things instead of making
> correctios
> >> > > > > and keeping the standard stable.
> >> > > > >
> >> > > > > This might be influenced by the number of different
> >discussions
> >> > > > > in this email list, but I believe this is not true.
> >> > > > > I try to summarize the proposed corrections and changes.
> >> > > > >
> >> > > > > The following things have been proposed:
> >> > > > >
> >> > > > > 1) Correction of ambiguities and problems with the
> >import mechanism.
> >> > > > >
> >> > > > > Effects: - Changes in the textual description
> >> > > > > - One syntax option which is related to
> >the import
> >> > > > > of language constructs that use module
> >parameter.
> >> > > > >
> >> > > > > 2) Removing an ambiguity for blocking and non-blocking
> >> > > > > procedure-based communication.
> >> > > > >
> >> > > > > Effects: - one optional keyword 'noblock'
> >> > > > > - Additions in the textual description.
> >> > > > >
> >> > > > >
> >> > > > > 3) Correction of the default mechanism, i.e.,
> replacing the
> >macro-based
> >> > > > > default mechanism by a more user-friendly
> >function-oriented default
> >> > > > > mechanism.
> >> > > > >
> >> > > > > Effects: - Changes of the textual description of
> >the default
> >> > > > > mechanism.
> >> > > > >
> >> > > > > - Replacement of 'named alt' by 'teststep'
> >> > > > > - Replacement of 'goto alt' by 'repeat'
> >> > > > > - Removal of the 'expand' keyword.
> >> > > > > - Introduction of a 'default' handle
> >> > > > >
> >> > > > > (The 'default' was introduced to solve
> >the older and known
> >> > > > > problem of multiple activation of the
> >same default with
> >> > > > > different
> >> > > > > actual parameters.)
> >> > > > >
> >> > > > >
> >> > > > > In addition there are requests for clearifying text
> >about existing
> >> > > > > restrictions
> >> > > > > on 'map' and 'connect' operations and timers.
> >Furthermore, the
> >structure
> >> > > > > of
> >> > > > > presenting the communication operations may be
> >improved, a section on
> >> > > > > type
> >> > > > > compatability has been proposed and the terminology
> >of synchronous and
> >> > > > > asynchronous
> >> > > > > communications should be changed to procedure-based
> >and message-based
> >> > > > > communication.
> >> > > > >
> >> > > > > If you count, you find three reasons for small
> >syntax changes (import,
> >> > > > > 'noblock',
> >> > > > > default handle) and three cosmetic corrections
> >('teststep', 'repeat',
> >> > > > > 'expand').
> >> > > > >
> >> > > > > Just a small remark to the cosmetic corrections: we
> >felt that the
> >> > > > > semantic changes
> >> > > > > with respect to defaults should be reflected in the
> >keywords. By
> >keeping
> >> > > > > the old
> >> > > > > keywords 'named alt' and 'goto alt', we thought that
> >there is the
> >danger
> >> > > > > to be misleaded
> >> > > > > by the old macro-based mechanism.
> >> > > > >
> >> > > > > I hope this convinces you that we really tried to
> >propose small
> >> > > > > syntactic changes only
> >> > > > > and put a lot of effort into removing ambiguities
> >from and improving
> >the
> >> > > > > readability of
> >> > > > > the textual description of TTCN-3.
> >> > > > >
> >> > > > > (Btw. I often use the term 'we'. With 'we' I do not
> >mean Anthony,
> >Colin
> >> > > > > and myself only,
> >> > > > > but also all the people of this email list that
> >helped to find,
> >discuss
> >> > > > > and resolve
> >> > > > > ambiguities in the standard and/or made
> >contributions to sections of
> >the
> >> > > > > standard.)
> >> > > > >
> >> > > > > Best regards
> >> > > > > Jens
> >> > > > >
> >> > > > >
> >> > > > > Csaba Koppany schrieb:
> >> > > > > >
> >> > > > > > Hello Jens and others,
> >> > > > > >
> >> > > > > > you wrote:
> >> > > > > > (The goto alt will be replaced by a repeat
> >statement in October.)
> >> > > > > >
> >> > > > > > Can you tell me what is the reason for this
> >change. As I see in the
> >ToR of STF
> >> > > > > > 187 there shall be only minor changes of the core
> >in edition 2.
> >> > > > > >
> >> > > > > > I do not agree modifications, which harms backward
> >compatibility and
> >change the
> >> > > > > > syntax, except major faults in the existing
> >language. We need a
> >stable TTCNv3
> >> > > > > > instead of several versions circulating around.
> >> > > > > >
> >> > > > > > So give a good reson for such kind of changes (as
> >I see this is not
> >the only one
> >> > > > > > planned.) I am really interested in others opinion
> >about that!
> >> > > > > >
> >> > > > > > Regards,
> >> > > > > > Csaba.
> >> > > > > > ============================================
> >> > > > > > Csaba Koppány
> >> > > > > > Ericsson Communications Systems Hungary Lim.
> >> > > > > > tel: +36 1 437-7930; fax: +36 1 437-7767
> >> > > > > > e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > > > > > ============================================
> >> > > > >
> >> > > > > --
> >> > > > >
> >> > > > >
> >=============================================================
> =========
> >> > > > > Dr. Jens Grabowski
> >> > > > > Institute for Telematics phone: +49 451 500 3723
> >> > > > > University of Luebeck fax: +49 451 500 3722
> >> > > > > Ratzeburger Allee 160 eMail:
> >This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > > > > D-23538 Luebeck or
> >This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > > > > (Germany) WWW:
> >www.itm.mu-luebeck.de
> >> > > > >
> >=============================================================
> =========
> >> > >
> >> > > --
> >> > >
> >> > >
> >=============================================================
> =========
> >> > > Dr. Jens Grabowski
> >> > > Institute for Telematics phone: +49 451 500 3723
> >> > > University of Luebeck fax: +49 451 500 3722
> >> > > Ratzeburger Allee 160 eMail:
> >This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > > D-23538 Luebeck or
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > > (Germany) WWW:
> >www.itm.mu-luebeck.de
> >> > >
> >=============================================================
> =========
> >>
> >> --
> >>
> >>
> >=============================================================
> =========
> >> Dr. Jens Grabowski
> >> Institute for Telematics phone: +49 451 500 3723
> >> University of Luebeck fax: +49 451 500 3722
> >> Ratzeburger Allee 160 eMail:
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> (Germany) WWW:
> >www.itm.mu-luebeck.de
> >>
> >=============================================================
> =========
> >
> >============================================
> >Csaba Koppány
> >Ericsson Communications Systems Hungary Lim.
> >tel: +36 1 437-7930; fax: +36 1 437-7767
> >e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >============================================
> >
>