Hi together,

I like also to add some comments to the discussion about the IMPORT problem.

The original problem is that the module paramters (and their values) of the
module
from which we like to import a certain definition is bound to the definition
itself.
This has the following two negative effects:
- lots of writing if the same module parameter is needed in several import
statements.
- possible inconsistencies if different values are assigned to the same
module
parameters in different import statements.

We can now either try to tackle one problem or both. We would like to tackle
both
but I am not sure that we can reach this goal. Of course, the inconsistency
problem
is the most important problem and the simple solution is:
- keep everything as it is, and
- add a consistency rule that disallows the assignment of different values
to the same
module parameter. This consistency rule can be checked statically by a
TTCN-3 compiler
(Btw. this is a proposal from Johan Nordin from Telelogic).

Another possibility is of course to remove the parameter assignment from the
import
statements and do it in some central place. This basically is the proposal
from Zoltan
(Ericsson) and this is also the way the problem is solved by the module
instance
proposal, or in other words: module instances are a new concept but only
solve our
second problem due to the central instantiation of the module, i.e., on a
syntactical level.

The problem we have with Johan's proposal is that it does not solve the
problem of
repeating identical module parameter assignments in several places.

The problem we have with Zoltan's proposal is that we would like to keep a
module
self-contained, i.e., everything needed for executing the module should be
within the module.

The problem we have with module instances is that it is a new concept and
beyond
a 'powerfull-and-nice-to-have-feature' argument, we do not see an urgent
need for such a
'powerful-and-nice-to-have-feature' for a TESTING language.


Our proposal tries to tackle both problems (unnecessary writing and
inconsistencies)
without introducing too much new syntax and without changing the concept.
This means:

a) the assignment of parameters is removed from individual import statements
b) the import of several definitions is grouped.

However, as Thomas has pointed out, we need consistency rules if we allow to
distribute the imports from one module in several parts of the definition
part. But we
believe that these rules are easier and more intuitive than rules on import
statements
for individual definitions.

The reason for allowing the distribution of import statements in several
parts of the
module definitions part was to keep flexibility in the style of writing a
module, e.g.,
someone may collect all import statements at one place someone else likes to
place the import statements near the definitions where the imported
definition is used.

However, at the moment I am more in favour to remove the flexibility of
distributing
import statements from the same module and to force the user to make the
import
of all definitions from another module at one place. This means I am in
favour
to keep our syntax proposal for import, but only allow one import definition
for
each module from which we like to import.

I believe that it would be simple to extend the syntax if it turns out that
the module
instance concept really is needed.

I also believe that this solution is inline with Zoltan's proposal, because
- we do not change the concept
- we remove the parameter assignment from the individual definitions to be
imported and
- basically we move the information from the proposed configuration file
back into the
module.

The drawback is of course that the syntax for the import statement has to be
changed.

Hope that helps to clarify things.

Best Regards
Jens

Dear Jens and colleagues,

having followed up the conversation concerning the input issue there is
one thing that I cannot understand namely self containment of modules.

So far I had the feeling that module parameters are in part a
replacement of TTCN PIXIT data and it is the responsibility of the test
execution environment to assign them values according to the users'
definitions. That is, module parameters come from outside and are not
embedded into the ATS itself!
This is the base consideration behind Zoltan's proposal, too.

If module parameters are invented only for data exchange between modules
then I wonder how do we include PIXIT-like data run-time?

Consider the following single module! Where do the values of A, B, C
come from? Is this module self-contained? If not then how does it become
self-contained?

module Example(integer A, charstring B, octetstring C)
{
...
}

Roland.
--
Roland Gecse [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax: +36-1-437 7792
Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u. 1., Hungary

Jens Grabowski wrote:
> However, at the moment I am more in favour to remove the flexibility of
> distributing
> import statements from the same module and to force the user to make the
> import
> of all definitions from another module at one place. This means I am in
> favour
> to keep our syntax proposal for import, but only allow one import definition
> for
> each module from which we like to import.
>
> I believe that it would be simple to extend the syntax if it turns out that
> the module
> instance concept really is needed.
>
> I also believe that this solution is inline with Zoltan's proposal, because
> - we do not change the concept
> - we remove the parameter assignment from the individual definitions to be
> imported and
> - basically we move the information from the proposed configuration file
> back into the
> module.
>
> The drawback is of course that the syntax for the import statement has to be
> changed.

Hi Roland,

with self-contained I mean that names and types of all
parameters relevant for this module should be known.
Their values have of course to be given at run-time when
the module is exectued. With respect to this definition
your example is self-contained.

Maybe I can describe our problem with Zoltan's proposal
in another way:

Assume that the compilation and linking of your module
'Example' was succesful and you now want to run your
testsuite.

Then I would like to type something in like

exec Example(5, "MyRun", '1286'O)

and I would expect that it then is exectuted and does
not stop with the error message:

* Execution has stopped, unresolved parameters in
* Module MyBlaBlaModule

We try to do is to avoid such messages by treating the
relevant parameters in the importing module and not in
the execution environment. That's the only difference
to Zoltan's proposal.

Regards
Jens










>

---

Original Message

---

> From: Roland Gecse [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 19 October 2001 12:40
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Import again
>
>
> Dear Jens and colleagues,
>
> having followed up the conversation concerning the input
> issue there is
> one thing that I cannot understand namely self containment of modules.
>
> So far I had the feeling that module parameters are in part a
> replacement of TTCN PIXIT data and it is the responsibility
> of the test
> execution environment to assign them values according to the users'
> definitions. That is, module parameters come from outside and are not
> embedded into the ATS itself!
> This is the base consideration behind Zoltan's proposal, too.
>
> If module parameters are invented only for data exchange
> between modules
> then I wonder how do we include PIXIT-like data run-time?
>
> Consider the following single module! Where do the values of A, B, C
> come from? Is this module self-contained? If not then how
> does it become
> self-contained?
>
> module Example(integer A, charstring B, octetstring C)
> {
> ...
> }
>
> Roland.
> --
> Roland Gecse [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
> Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax:
> +36-1-437 7792
> Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u. 1., Hungary
>
> Jens Grabowski wrote:
> > However, at the moment I am more in favour to remove the
> flexibility of
> > distributing
> > import statements from the same module and to force the
> user to make the
> > import
> > of all definitions from another module at one place. This
> means I am in
> > favour
> > to keep our syntax proposal for import, but only allow one
> import definition
> > for
> > each module from which we like to import.
> >
> > I believe that it would be simple to extend the syntax if
> it turns out that
> > the module
> > instance concept really is needed.
> >
> > I also believe that this solution is inline with Zoltan's
> proposal, because
> > - we do not change the concept
> > - we remove the parameter assignment from the individual
> definitions to be
> > imported and
> > - basically we move the information from the proposed
> configuration file
> > back into the
> > module.
> >
> > The drawback is of course that the syntax for the import
> statement has to be
> > changed.
>

Hi,

Just for my clarification:

In current TTCN-2 I can define test suite parameters in any module and this is very convenient from the point of view reusability. I can define TSPs related to each protocol in its own module and it always will move with the module when the module it copied to another test suite.

Would this feature be endangered with this new concept or not? If it would, then I do not think, it is acceptable from the users point of view.

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: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Friday, October 19, 2001 2:01 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Import again
>
>
>Hi Roland,
>
>with self-contained I mean that names and types of all
>parameters relevant for this module should be known.
>Their values have of course to be given at run-time when
>the module is exectued. With respect to this definition
>your example is self-contained.
>
>Maybe I can describe our problem with Zoltan's proposal
>in another way:
>
> Assume that the compilation and linking of your module
> 'Example' was succesful and you now want to run your
> testsuite.
>
> Then I would like to type something in like
>
> exec Example(5, "MyRun", '1286'O)
>
> and I would expect that it then is exectuted and does
> not stop with the error message:
>
> * Execution has stopped, unresolved parameters in
> * Module MyBlaBlaModule
>
>We try to do is to avoid such messages by treating the
>relevant parameters in the importing module and not in
>the execution environment. That's the only difference
>to Zoltan's proposal.
>
>Regards
>Jens
>
>
>
>
>
>
>
>
>
>
>>

---

Original Message

---

>> From: Roland Gecse [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>> Sent: 19 October 2001 12:40
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: Import again
>>
>>
>> Dear Jens and colleagues,
>>
>> having followed up the conversation concerning the input
>> issue there is
>> one thing that I cannot understand namely self containment
>of modules.
>>
>> So far I had the feeling that module parameters are in part a
>> replacement of TTCN PIXIT data and it is the responsibility
>> of the test
>> execution environment to assign them values according to the users'
>> definitions. That is, module parameters come from outside and are not
>> embedded into the ATS itself!
>> This is the base consideration behind Zoltan's proposal, too.
>>
>> If module parameters are invented only for data exchange
>> between modules
>> then I wonder how do we include PIXIT-like data run-time?
>>
>> Consider the following single module! Where do the values of A, B, C
>> come from? Is this module self-contained? If not then how
>> does it become
>> self-contained?
>>
>> module Example(integer A, charstring B, octetstring C)
>> {
>> ...
>> }
>>
>> Roland.
>> --
>> Roland Gecse [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax:
>> +36-1-437 7792
>> Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u.
>1., Hungary
>>
>> Jens Grabowski wrote:
>> > However, at the moment I am more in favour to remove the
>> flexibility of
>> > distributing
>> > import statements from the same module and to force the
>> user to make the
>> > import
>> > of all definitions from another module at one place. This
>> means I am in
>> > favour
>> > to keep our syntax proposal for import, but only allow one
>> import definition
>> > for
>> > each module from which we like to import.
>> >
>> > I believe that it would be simple to extend the syntax if
>> it turns out that
>> > the module
>> > instance concept really is needed.
>> >
>> > I also believe that this solution is inline with Zoltan's
>> proposal, because
>> > - we do not change the concept
>> > - we remove the parameter assignment from the individual
>> definitions to be
>> > imported and
>> > - basically we move the information from the proposed
>> configuration file
>> > back into the
>> > module.
>> >
>> > The drawback is of course that the syntax for the import
>> statement has to be
>> > changed.
>>
>

Hi Gyorgy,

no, this TTCN-2 feature is not endangered.

TTCN-2 is not very clear with respect to the import and resolution
of module parameters. According to my understanding of TTCN-2 you have to
import all relevant module parameters explicitly and, after the
import, these parameters will also be parameters of the importing
module.

In TTCN-3, you do not have to import the relevant module parameters
explicitly, i.e., by means of import statements, but you have to
explain their resolution. This means, you can resolve them
- by the assignment of module constants,
- by the assignment of external constants,
- by the assignment of concrete values,
- by the use of the default values in the imported module (if nothing is
specified), or
- by making them to module parameters of the importing module (this is
somehow
identical to the TTCN-2 mechanism).

With respect to this view you gain more flexibility in TTCN-3.

Best regards
Jens




>

---

Original Message

---

> From: Gyorgy Rethy (ETH) [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 19 October 2001 15:22
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Import again
>
>
> Hi,
>
> Just for my clarification:
>
> In current TTCN-2 I can define test suite parameters in any
> module and this is very convenient from the point of view
> reusability. I can define TSPs related to each protocol in
> its own module and it always will move with the module when
> the module it copied to another test suite.
>
> Would this feature be endangered with this new concept or
> not? If it would, then I do not think, it is acceptable from
> the users point of view.
>
> 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: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >Sent: Friday, October 19, 2001 2:01 PM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: Import again
> >
> >
> >Hi Roland,
> >
> >with self-contained I mean that names and types of all
> >parameters relevant for this module should be known.
> >Their values have of course to be given at run-time when
> >the module is exectued. With respect to this definition
> >your example is self-contained.
> >
> >Maybe I can describe our problem with Zoltan's proposal
> >in another way:
> >
> > Assume that the compilation and linking of your module
> > 'Example' was succesful and you now want to run your
> > testsuite.
> >
> > Then I would like to type something in like
> >
> > exec Example(5, "MyRun", '1286'O)
> >
> > and I would expect that it then is exectuted and does
> > not stop with the error message:
> >
> > * Execution has stopped, unresolved parameters in
> > * Module MyBlaBlaModule
> >
> >We try to do is to avoid such messages by treating the
> >relevant parameters in the importing module and not in
> >the execution environment. That's the only difference
> >to Zoltan's proposal.
> >
> >Regards
> >Jens
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>

---

Original Message

---

> >> From: Roland Gecse [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >> Sent: 19 October 2001 12:40
> >> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> Subject: Re: Import again
> >>
> >>
> >> Dear Jens and colleagues,
> >>
> >> having followed up the conversation concerning the input
> >> issue there is
> >> one thing that I cannot understand namely self containment
> >of modules.
> >>
> >> So far I had the feeling that module parameters are in part a
> >> replacement of TTCN PIXIT data and it is the responsibility
> >> of the test
> >> execution environment to assign them values according to the users'
> >> definitions. That is, module parameters come from outside
> and are not
> >> embedded into the ATS itself!
> >> This is the base consideration behind Zoltan's proposal, too.
> >>
> >> If module parameters are invented only for data exchange
> >> between modules
> >> then I wonder how do we include PIXIT-like data run-time?
> >>
> >> Consider the following single module! Where do the values
> of A, B, C
> >> come from? Is this module self-contained? If not then how
> >> does it become
> >> self-contained?
> >>
> >> module Example(integer A, charstring B, octetstring C)
> >> {
> >> ...
> >> }
> >>
> >> Roland.
> >> --
> >> Roland Gecse [ETH/RL/S] This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> Tel.: +36-1-437:7618, ECN: 831:, MS: +36-30-2030881, Fax:
> >> +36-1-437 7792
> >> Ericsson Telecommunications Ltd., 1037 Budapest, Laborc u.
> >1., Hungary
> >>
> >> Jens Grabowski wrote:
> >> > However, at the moment I am more in favour to remove the
> >> flexibility of
> >> > distributing
> >> > import statements from the same module and to force the
> >> user to make the
> >> > import
> >> > of all definitions from another module at one place. This
> >> means I am in
> >> > favour
> >> > to keep our syntax proposal for import, but only allow one
> >> import definition
> >> > for
> >> > each module from which we like to import.
> >> >
> >> > I believe that it would be simple to extend the syntax if
> >> it turns out that
> >> > the module
> >> > instance concept really is needed.
> >> >
> >> > I also believe that this solution is inline with Zoltan's
> >> proposal, because
> >> > - we do not change the concept
> >> > - we remove the parameter assignment from the individual
> >> definitions to be
> >> > imported and
> >> > - basically we move the information from the proposed
> >> configuration file
> >> > back into the
> >> > module.
> >> >
> >> > The drawback is of course that the syntax for the import
> >> statement has to be
> >> > changed.
> >>
> >
>

On Fri, 19 Oct 2001, Jens Grabowski wrote:

> Hi together,
>
> I like also to add some comments to the discussion about the IMPORT problem.
>
> We can now either try to tackle one problem or both. We would like to tackle
> both
> but I am not sure that we can reach this goal. Of course, the inconsistency
> problem
> is the most important problem and the simple solution is:
> - keep everything as it is, and
> - add a consistency rule that disallows the assignment of different values
> to the same
> module parameter. This consistency rule can be checked statically by a
> TTCN-3 compiler
> (Btw. this is a proposal from Johan Nordin from Telelogic).

Should the inconsistency rule be local to one module or to all modules
that are used (directly or indirectly).

If the first, you would possibly still have different
module instances at runtime (only in different modules).
If the second, you can't check that statically, as
- external constants can be used to instantiate module parameters
- no modularized compilation is possible anymore

So, the first would be - in my view - the only acceptable solution.
But, if you have different module instances globally, why not allow
them locally (in one module, as we propose), as well?

> The problem we have with module instances is that it is a new concept and
> beyond
> a 'powerfull-and-nice-to-have-feature' argument, we do not see an urgent
> need for such a
> 'powerful-and-nice-to-have-feature' for a TESTING language.

Actually, we just tried to add that to the syntactic level what
is there on the semantic level already - multiple instances of the
same module.

> The drawback is of course that the syntax for the import statement has to be
> changed.

In our approach, it would only lose the parameter list (which would appear
in the module instance declaration statement instead). So that is surely
no big change - neither syntactically, nor semantically.

Jacob Wieland, TU-Berlin