Another question tangentially related to timers:

Component-type compatibility depends on "identical initial durations"
for the timer instances (clause 6.3.3). What exactly does this mean?
Identical expressions, or identical values? The duration of a timer
instance is not restricted to a constant expression (and, for example,
LibCommon_Sync.ttcn from the IPv6 test suite has a non-constant timer
duration, which depends on a module parameter). If dynamic expressions
are allowed, this is another facet of type compatibility that isn't
statically decidable---is this intentional? Moreover, when is the
duration expression evaluated? (Module initialization? Component
creation?)

The question probably also applies to regular variable declarations at
the component level, but 6.3.3 at least talks about "initialization
values" in this case.

--
Regards,
Mike

Hello Michael,

We had come across this issue also last week, in the latest working session of STF349. The intention is actually that an identifier can be declared only once in a component type or the component types from which it is extended.
The case that a component type A extend B and C, and that both B and C extend a component type D is not considered to introduce the declarations of D twice. Hence this case would be allowed.

Please have a look at the corresponding CR (t-ort.etsi.org/view.php?id=3943) and the resolution that is attached to it.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Michael Sperber
>Sent: Monday, 18. August 2008 13:42
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Component-type compatibility vs. timer duration
>
>Another question tangentially related to timers:
>
>Component-type compatibility depends on "identical initial durations"
>for the timer instances (clause 6.3.3). What exactly does this mean?
>Identical expressions, or identical values? The duration of a
>timer instance is not restricted to a constant expression
>(and, for example, LibCommon_Sync.ttcn from the IPv6 test
>suite has a non-constant timer duration, which depends on a
>module parameter). If dynamic expressions are allowed, this
>is another facet of type compatibility that isn't statically
>decidable---is this intentional? Moreover, when is the
>duration expression evaluated? (Module initialization? Component
>creation?)
>
>The question probably also applies to regular variable
>declarations at the component level, but 6.3.3 at least talks
>about "initialization values" in this case.
>
>--
>Regards,
>Mike
>

Thomas Deiss <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> We had come across this issue also last week, in the latest working
> session of STF349. The intention is actually that an identifier can be
> declared only once in a component type or the component types from
> which it is extended.

That isn't what I meant. (Even though the CR is also interesting!)

I probably wasn't being very clear---I'll try to rephrase. Consider this
component-type declaration:

type component C {
timer t := <exp>;
}

What are the restrictions on <exp>? The standard places no special
restrictions, and the IPv6 code suggests it can be a dynamic expression
(i.e. one that can't be evaluated at compile time). If that's the case,
when is it evaluated? At module initialization time? At component
declaration time? At component creation time? (I think module
initialization time is the only option that doesn't lead to
inconsistencies further down the line.)

Now, consider this:

type component C2 {
timer t := <exp2>;
}

(No extension is involved.) How and when is it decided whether C and C2
are compatible? The standard says that the "durations" must be
identical, but what does this mean? Does it mean that <exp> and <exp2>
are textually identical? Or that they have the same value?

--
Regards,
Mike

Hello Mike,

Sorry, seems that I answered too fast.
Please find the answers to your issues below.

Best regards

Thomas


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Michael Sperber
>Sent: Monday, 18. August 2008 21:27
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Component-type compatibility vs. timer duration
>
>Thomas Deiss <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>
>> We had come across this issue also last week, in the latest working
>> session of STF349. The intention is actually that an
>identifier can be
>> declared only once in a component type or the component types from
>> which it is extended.
>
>That isn't what I meant. (Even though the CR is also interesting!)
>
>I probably wasn't being very clear---I'll try to rephrase.
>Consider this component-type declaration:
>
>type component C {
> timer t := <exp>;
>}
>
>What are the restrictions on <exp>? The standard places no
>special restrictions, and the IPv6 code suggests it can be a
>dynamic expression (i.e. one that can't be evaluated at
>compile time). If that's the case, when is it evaluated? At
>module initialization time? At component declaration time?
>At component creation time? (I think module initialization
>time is the only option that doesn't lead to inconsistencies
>further down the line.)

The expression is used within a type definition. Actually it should be
possible to evaluate <expr> at compile time. This issue has also caused
a lot of discussion this year, the corresponding CR is 2152.

At the moment I do not have the IPv6 test suite in front of me.
Therefore I cannot comment on this specific case. Please be so kind and
send the specific definition you have in mind.



>
>Now, consider this:
>
>type component C2 {
> timer t := <exp2>;
>}
>
>(No extension is involved.) How and when is it decided
>whether C and C2 are compatible? The standard says that the
>"durations" must be identical, but what does this mean? Does
>it mean that <exp> and <exp2> are textually identical? Or
>that they have the same value?

It depends on the case when type compatibility is decided. In most cases
it can be decided at run time when the type compatibility rules are
violated. With compoenent references of various component types it is
possible to construct examples, where typical compilers would postpone
the compatibility check to runtime. (Note that a) there can be TTCN-3
interpreters, and b) for most of the semantic checks there is no
requirement whether they are done compile or runtime, although I prefer
that checks are done as early as possible).

Regarding the identity it is not necessary that the definitions have to
be textual identical. If the expressions can be determined at compile
time, as mentioned before, then the check on identity can be done by a
compiler.

>
>--
>Regards,
>Mike
>

Thanks for tracking down the discussion on this!

Thomas Deiss <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> The expression is used within a type definition. Actually it should be
> possible to evaluate <expr> at compile time. This issue has also caused
> a lot of discussion this year, the corresponding CR is 2152.
>
> At the moment I do not have the IPv6 test suite in front of me.
> Therefore I cannot comment on this specific case. Please be so kind and
> send the specific definition you have in mind.

LibCommon_Sync.ttcn has this:

modulepar {float PX_TSYNC_TIME_LIMIT := 120.0}

...

type component ServerSyncComp {
port SyncPort syncPort;
timer tc_sync := PX_TSYNC_TIME_LIMIT;
timer tc_shutDown := PX_TSHUT_DOWN_TIME_LIMIT;
}

--
Regards,
Mike