Hello All!

I agree with you Antti!

There must be some kind of order... ;)

I use .ttcn myself, I am not sure why bother to use .ttcn3,
but if you have mixed ttcn-2 and ttcn-3 environment I suppose that it could make sense.

OK.. In 10 years, it might not be the hottest test language, but I actually believe that it will be around...
Fortran is... Even Cobol might be around in some places.. ;)
So there is, in my opinion, a need for some kind of 'standard' regarding the extension...
Not for the tool or language itself, but, as Antti indicated, for the user's comfort..

Take care!

---

Jörgen Svensson R
System Tester
Ericsson AB Site South Sweden

---

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 Antti Hyrkkanen
Sent: den 12 januari 2007 11:13
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-3 source file extension

>

---

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 Shicheng Hu
> Sent: 12. tammikuuta 2007 10:54
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: TTCN-3 source file extension
>
> Hi Bernard and Theo
>
> Thank you for the answers.
> Exactly for the same historical reason I like 3mp. I have a few
> thoughts and would like to share with you.
>

[snip]

> Similar to the creation of TTCN3, we didn't change TTCN, why can TTCN3
> source file extension not be called .3mp? You could invent a new
> meaning for mp in the TTCN3 context.
>
> Best regards
> Shicheng

When I saw this .3mp suffix, the first thing that came into my mind is that it is a some tool specific TTCN-3 module parameter file for a
.ttcn3 file. I might use such extension for module parameter use, if the used tool does not specify the preferable extension.

Even though the extension might be cosmetic from OS point of view, it is not cosmetic how you need to live with them.

One could probably write generic Makefiles that uses variable that specifies the known TTCN-3 extensions, but in reality they will assume that certain extensions are used. If you look at GNU Make manual, there's stuff like this in the case of C language

foo := a.o b.o c.o
bar := $(foo:.o=.c)

--
objects = foo.o bar.o
all: $(objects)
$(objects): %.o: %.c
$(CC) -c $(CFLAGS) $< -o $@

If you happen to received from your collaborator TTCN-3 files and they happen to use different extensions, you won't like it. At least I won't like.

When I use scripts and commands to find files and perform any operations on them, I often use wildcards and extensions. If there are several extensions for the same file content, it will become annoying.

If some C programmer decided to use suffixes .ctu, .cl, .cs, or whatever, (ctu= c translation unit, .cl = c language, cs=c-source) for his .c files, how many of you would touch them? If you are like me, you might wonder how strange the content will be since such exotic extensions have been used.

I would like to see only one extension. More only if the content format potentially differs (.c, .cc, .cxx). To me it shows immaturity of the language if there's no well established extension that all people use.
What extension is the best one, I don't know. I've been using .ttcn since it is less long than .ttcn3, but .ttcn3 is very clear about its content. Even shorted extension might be nice, such as .t3.

Did some googling, and found out that .T3 is already used for Tarshare File, whatever that might.

Antti

Hi,

I small reflection to Shicheng's claim that TTCN-2 is still used more than TTCN-3. Within Ericsson this is not true for sure. At some "exotic" places they still may use legacy TTCN-2 code for regression testing but no TTCN-2 tool is developed or even maintained any more. All TTCN-2 stuff is used "as is" and new code is written in TTCN-3. Most users have changed to TTCN-3 years ago and there are several areas where they have replaced other solutions with TTCN-3. Hence the TTCN-3 user base it bigger today then the TTCN-2 user base ever was. Of course, the UE testing area is an exception, as they are binded to certified implementations of 3GPP test suites.

Regarding the file extension, I do not think that it is an issue at all. With any file manager takes cca. 5 sec. to change extensions of all files in a complete directory tree to anything else the user likes... TTCN-3 does not deals with the technique of storing modules ... probably on purpose. As myself, I do not think this should be standardized (= users freedom limited by a paper). For example with C/C++ there are also several conventions used (c++, cpp, cc etc.). With TTCN-3 different user groups have different conventions; probably most of them at the company level; but why to force Ericsson users to have the same convention as used in other companies, while it would add no value? This shall be simply solved by tools (btw. tools should allow other extensions too even if there was a standardized TTCN-3 extension). I'm sure that just like C/C++ there will be not more than 3-4 conventional extensions used.

But if I had to choose, I would also select .ttcn. None of the proposed extensions would identify the TTCN-3 language edition(it can be done within the module), why should we identify the language version in the extension? There was no practical argument to do this. Yet.

BR, Gyorgy

>

---

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 Jörgen
>Svensson R (KA/EAB)
>Sent: Friday, 2007 January 12. 11:23 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TTCN-3 source file extension
>
>Hello All!
>
>I agree with you Antti!
>
>There must be some kind of order... ;)
>
>I use .ttcn myself, I am not sure why bother to use .ttcn3,
>but if you have mixed ttcn-2 and ttcn-3 environment I suppose
>that it could make sense.
>
>OK.. In 10 years, it might not be the hottest test language,
>but I actually believe that it will be around...
>Fortran is... Even Cobol might be around in some places.. ;)
>So there is, in my opinion, a need for some kind of 'standard'
>regarding the extension...
>Not for the tool or language itself, but, as Antti indicated,
>for the user's comfort..
>
>Take care!
>
>

---

>Jörgen Svensson R
>System Tester
>Ericsson AB Site South Sweden
>
>
>
>
>
>

---

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 Antti Hyrkkanen
>Sent: den 12 januari 2007 11:13
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TTCN-3 source file extension
>
>>

---

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 Shicheng Hu
>> Sent: 12. tammikuuta 2007 10:54
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: TTCN-3 source file extension
>>
>> Hi Bernard and Theo
>>
>> Thank you for the answers.
>> Exactly for the same historical reason I like 3mp. I have a few
>> thoughts and would like to share with you.
>>
>
>[snip]
>
>> Similar to the creation of TTCN3, we didn't change TTCN, why
>can TTCN3
>> source file extension not be called .3mp? You could invent a new
>> meaning for mp in the TTCN3 context.
>>
>> Best regards
>> Shicheng
>
>When I saw this .3mp suffix, the first thing that came into my
>mind is that it is a some tool specific TTCN-3 module
>parameter file for a
>.ttcn3 file. I might use such extension for module parameter
>use, if the used tool does not specify the preferable extension.
>
>Even though the extension might be cosmetic from OS point of
>view, it is not cosmetic how you need to live with them.
>
>One could probably write generic Makefiles that uses variable
>that specifies the known TTCN-3 extensions, but in reality
>they will assume that certain extensions are used. If you look
>at GNU Make manual, there's stuff like this in the case of C language
>
> foo := a.o b.o c.o
> bar := $(foo:.o=.c)
>
>--
> objects = foo.o bar.o
> all: $(objects)
> $(objects): %.o: %.c
> $(CC) -c $(CFLAGS) $< -o $@
>
>If you happen to received from your collaborator TTCN-3 files
>and they happen to use different extensions, you won't like
>it. At least I won't like.
>
>When I use scripts and commands to find files and perform any
>operations on them, I often use wildcards and extensions. If
>there are several extensions for the same file content, it
>will become annoying.
>
>If some C programmer decided to use suffixes .ctu, .cl, .cs,
>or whatever, (ctu= c translation unit, .cl = c language,
>cs=c-source) for his .c files, how many of you would touch
>them? If you are like me, you might wonder how strange the
>content will be since such exotic extensions have been used.
>
>I would like to see only one extension. More only if the
>content format potentially differs (.c, .cc, .cxx). To me it
>shows immaturity of the language if there's no well
>established extension that all people use.
>What extension is the best one, I don't know. I've been using
>.ttcn since it is less long than .ttcn3, but .ttcn3 is very
>clear about its content. Even shorted extension might be nice,
>such as .t3.
>
>Did some googling, and found out that .T3 is already used for
>Tarshare File, whatever that might.
>
>Antti
>

We don't suffer that much (mabe because we enjoy this!), but our sources
at IRISA are "tool independent" and we produce "tool dependent" sources
with the Makefile, that afterward, invokes compilers and generates
executables. Not with 5 or 7 tools, but with the ones we work with.
We agree on the fact that standardization of file extensions would be
great for the user's confort :-)

Ariel

Stephan Schulz wrote:
> Hi,
>
> I can only add to this discussion that ETSI STFs are probably the people
> suffering most from this issue as they are _required_ to compile test
> suites (especially Shicheng) with up to 5 different TTCN-3 tools (seems
> like now we have to soon increment that to 7).
>
> I think it would be a nice idea to start thinking about a common
> extension. I imagine it should not be difficult for tool vendors to
> support their originial file extensions in addition to the standardized
> one. In other words one could require support of a common extension but
> allow also to use others.
>
> Just an idea,
> Stephan
>
>
>>

---

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 Antti Hyrkkanen
>> Sent: 12 January 2007 11:13
>> To: TTCN3
>> Subject: Re: TTCN-3 source file extension
>>
>>
>>>

---

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 Shicheng Hu
>>> Sent: 12. tammikuuta 2007 10:54
>>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>> Subject: Re: TTCN-3 source file extension
>>>
>>> Hi Bernard and Theo
>>>
>>> Thank you for the answers.
>>> Exactly for the same historical reason I like 3mp. I have a few
>>> thoughts and would like to share with you.
>>>
>>>
>> [snip]
>>
>>
>>> Similar to the creation of TTCN3, we didn't change TTCN,
>>>
>> why can TTCN3
>>
>>> source file extension not be called .3mp? You could invent a new
>>> meaning for mp in the TTCN3 context.
>>>
>>> Best regards
>>> Shicheng
>>>
>> When I saw this .3mp suffix, the first thing that came into
>> my mind is that it is a some tool specific TTCN-3 module
>> parameter file for a
>> .ttcn3 file. I might use such extension for module parameter
>> use, if the used tool does not specify the preferable extension.
>>
>> Even though the extension might be cosmetic from OS point of
>> view, it is not cosmetic how you need to live with them.
>>
>> One could probably write generic Makefiles that uses variable
>> that specifies the known TTCN-3 extensions, but in reality
>> they will assume that certain extensions are used. If you
>> look at GNU Make manual, there's stuff like this in the case
>> of C language
>>
>> foo := a.o b.o c.o
>> bar := $(foo:.o=.c)
>>
>> --
>> objects = foo.o bar.o
>> all: $(objects)
>> $(objects): %.o: %.c
>> $(CC) -c $(CFLAGS) $< -o $@
>>
>> If you happen to received from your collaborator TTCN-3 files
>> and they happen to use different extensions, you won't like
>> it. At least I won't like.
>>
>> When I use scripts and commands to find files and perform any
>> operations on them, I often use wildcards and extensions. If
>> there are several extensions for the same file content, it
>> will become annoying.
>>
>> If some C programmer decided to use suffixes .ctu, .cl, .cs,
>> or whatever, (ctu= c translation unit, .cl = c language,
>> cs=c-source) for his .c files, how many of you would touch
>> them? If you are like me, you might wonder how strange the
>> content will be since such exotic extensions have been used.
>>
>> I would like to see only one extension. More only if the
>> content format potentially differs (.c, .cc, .cxx). To me it
>> shows immaturity of the language if there's no well
>> established extension that all people use.
>> What extension is the best one, I don't know. I've been using
>> .ttcn since it is less long than .ttcn3, but .ttcn3 is very
>> clear about its content. Even shorted extension might be
>> nice, such as .t3.
>>
>> Did some googling, and found out that .T3 is already used for
>> Tarshare File, whatever that might.
>>
>> Antti
>>
>>
>
>
>

Hi,

I also think that it is time to agree on a common extension - and to agree
if there is a 1:1 or 1:n between file and module. I think personally that
1:1 is handier.

Looking at existing file extensions (for example
en.wikipedia.org/wiki/List_of_file_extensions_by_alphabet)

.t is already taken
.ttcn and .ttcn3 are too long imho

.t3 seems to be "available"
(btw. it would not be the only case where the version is part of the
extension, e.g. .mp2 or .mp3)

Also, it would be nice to agree on a common way to denote the TTCN-3 version
a module is using - e.g. by reusing the identifiers that have been defined
for the import of TTCN-3 modules.

Furthermore, we could agree on a way to denote which character set is being
used. This would work of course only if up until this information is
provided any previous characters (ASCII-valued bytes) stand for ASCII
characters. So, the meta-information about the character set (and the TTCN-3
version) should be as early as possible in the TTCN-3 module. Hence, the use
of a module attribute would not help for this purpose.

With best regards,

Ina.


>

---

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 Risto Teittinen
> Sent: Friday, January 12, 2007 12:15 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: TTCN-3 source file extension
>
> Hi,
>
> I don't have a problem with a common extension.
>
> I guess this issue has to be handled via a CR but I'll
> provide my proposal here.
>
> I propose 'ttcn' with following arguments. It simply
> indicates that it's all about TTCN. It does not specify is it
> TTCN-2, TTCN-3 or TTCN-4 but I think it's only a good idea.
> Why so? Personally I don't like idea of using numbers in the
> language name to refer a version of the language (e.g. TTCN-2
> and TTCN-3). If a version number is used in a suffix, it
> implicitly means that whenever TTCN-4 shows up a new suffix is needed.
> In my opinion when a language evolves it should not change
> the name of the language. There are other ways to handle it.
> Also, you don't see any version numbering in other common
> file extensions for other languages, e.g. C (.c), ASN.1 (.asn) etc.
>
> The only bad thing in 'ttcn' is that it is a bit too long for
> my taste.
> It could be shorter, e.g 't3' that Antti mentioned or even
> 't' as TTCN or testing.
>
>
> BR,
> Risto
>
>
> >

---

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 Stephan Schulz
> >Sent: 12 January, 2007 12:29
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: TTCN-3 source file extension
> >
> >Hi,
> >
> >I can only add to this discussion that ETSI STFs are probably the
> >people suffering most from this issue as they are _required_
> to compile
> >test suites (especially Shicheng) with up to 5 different
> TTCN-3 tools
> >(seems like now we have to soon increment that to 7).
> >
> >I think it would be a nice idea to start thinking about a common
> >extension. I imagine it should not be difficult for tool vendors to
> >support their originial file extensions in addition to the
> standardized
> >one. In other words one could require support of a common
> extension but
> >allow also to use others.
> >
> >Just an idea,
> >Stephan
> >
> >>

---

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 Antti Hyrkkanen
> >> Sent: 12 January 2007 11:13
> >> To: TTCN3
> >> Subject: Re: TTCN-3 source file extension
> >>
> >> >

---

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 Shicheng Hu
> >> > Sent: 12. tammikuuta 2007 10:54
> >> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >> > Subject: Re: TTCN-3 source file extension
> >> >
> >> > Hi Bernard and Theo
> >> >
> >> > Thank you for the answers.
> >> > Exactly for the same historical reason I like 3mp. I have a few
> >> > thoughts and would like to share with you.
> >> >
> >>
> >> [snip]
> >>
> >> > Similar to the creation of TTCN3, we didn't change TTCN,
> >> why can TTCN3
> >> > source file extension not be called .3mp? You could invent a new
> >> > meaning for mp in the TTCN3 context.
> >> >
> >> > Best regards
> >> > Shicheng
> >>
> >> When I saw this .3mp suffix, the first thing that came into
> >my mind is
> >> that it is a some tool specific TTCN-3 module parameter file for a
> >> .ttcn3 file. I might use such extension for module
> parameter use, if
> >> the used tool does not specify the preferable extension.
> >>
> >> Even though the extension might be cosmetic from OS point of
> >view, it
> >> is not cosmetic how you need to live with them.
> >>
> >> One could probably write generic Makefiles that uses variable that
> >> specifies the known TTCN-3 extensions, but in reality they
> >will assume
> >> that certain extensions are used. If you look at GNU Make manual,
> >> there's stuff like this in the case of C language
> >>
> >> foo := a.o b.o c.o
> >> bar := $(foo:.o=.c)
> >>
> >> --
> >> objects = foo.o bar.o
> >> all: $(objects)
> >> $(objects): %.o: %.c
> >> $(CC) -c $(CFLAGS) $< -o $@
> >>
> >> If you happen to received from your collaborator TTCN-3
> >files and they
> >> happen to use different extensions, you won't like it. At least I
> >> won't like.
> >>
> >> When I use scripts and commands to find files and perform any
> >> operations on them, I often use wildcards and extensions. If
> >there are
> >> several extensions for the same file content, it will become
> >annoying.
> >>
> >> If some C programmer decided to use suffixes .ctu, .cl, .cs, or
> >> whatever, (ctu= c translation unit, .cl = c language,
> >> cs=c-source) for his .c files, how many of you would touch
> them? If
> >> you are like me, you might wonder how strange the content will be
> >> since such exotic extensions have been used.
> >>
> >> I would like to see only one extension. More only if the content
> >> format potentially differs (.c, .cc, .cxx). To me it shows
> >immaturity
> >> of the language if there's no well established extension that all
> >> people use.
> >> What extension is the best one, I don't know. I've been
> using .ttcn
> >> since it is less long than .ttcn3, but .ttcn3 is very clear
> >about its
> >> content. Even shorted extension might be nice, such as .t3.
> >>
> >> Did some googling, and found out that .T3 is already used
> >for Tarshare
> >> File, whatever that might.
> >>
> >> Antti
> >>
> >
>

Hi,

> I also think that it is time to agree on a common extension -
> and to agree
> if there is a 1:1 or 1:n between file and module. I think
> personally that
> 1:1 is handier.
>
> Looking at existing file extensions (for example
> en.wikipedia.org/wiki/List_of_file_extensions_by_alphabet)
>
> .t is already taken
> .ttcn and .ttcn3 are too long imho

IMHO .ttcn is better than t3. Consider the case of .htm vs. .html.


Gabor
Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer

Ericsson Hungary Ltd.
Research & Development

Hi!

I agree with Gábor!

I also think .ttcn would be better than .t3, which I think rather implies .ttt (compare w3 - www)

(Yes, I know.. Perhaps not the best argument, but still, it's an argument.. ;)

/Jörgen Svensson
Ericsson AB, Site South Sweden

---

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 Gábor Ziegler (IJ/ETH)
Sent: den 14 januari 2007 15:28
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-3 source file extension

Hi,

> I also think that it is time to agree on a common extension - and to
> agree if there is a 1:1 or 1:n between file and module. I think
> personally that
> 1:1 is handier.
>
> Looking at existing file extensions (for example
> en.wikipedia.org/wiki/List_of_file_extensions_by_alphabet)
>
> .t is already taken
> .ttcn and .ttcn3 are too long imho

IMHO .ttcn is better than t3. Consider the case of .htm vs. .html.


Gabor
Gábor Ziegler M.Sc.E.E., dr.univ
Test System Engineer

Ericsson Hungary Ltd.
Research & Development