Hi,

does anyone (especially from the TTCN-3 standard maintanence team) know WHY charstring subtyping does not allow combinations of value lists AND ranges?
Ironically this is used in ETSIs common lib code .. but so far no TTCN-3 tool has complained about it, i.e.,

type charstring AlphaNum ("0".."9","a".."z","A".."Z");

please enlighten me,
stephan

As per §6.1.2.5.1 of 'ETSI ES 201 873-1 V3.2.1 Part 1: TTCN 3 Core Language'

<<snip>>
Within charstring and universal charstring sub-type definitions it is not allowed to mix pattern, list or range constraints.
<<snip>>


o

---

o
Stephan Schulz, Ph.D.
ETSI - World Class Standards
Sr. Technical Expert
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
Tel: +33 49294 4964
Mobile: +33 63334 8269
Fax: +33 49365 4716
o

---

o

Hello Stephan,

a couple of comments:

Actually I do not know where this restriction comes from, hence I can only speculate. I think the different handling of mixing subtyping for integers and charstrings might come from the different meaning of ranges for integers and charstrings. For integers a range can be seen as a shorthand for a lengthy value list. For charstrings it means to restrict the range of letters. Hence
type charstring Lower ("a".."z")
denotes the strings build from lowercase letters.
In contrast a value list defines some strings. Mixing range and value list notation for charstrings can be seen as providing at the same time information on some strings and on the characters that can be used for all strings. But as said, this is only speculation.

Regarding patterns: this _might_ be excluded as pattern are strictly more expressive that ranges and value lists and then two different mechanisms for the same problem would be used.

I suggest that you replace the specific subtype restriction in the ETSI common lib code by a corresponding pattern. Then you would be on the safe side.

And in case you feel that removing this restriction would ease the use of the language, I guess you have to write a CR :-)

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 Stephan Schulz
Sent: Friday, 14. December 2007 12:43
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Reasons for string subtyping?


Hi,

does anyone (especially from the TTCN-3 standard maintanence team) know WHY charstring subtyping does not allow combinations of value lists AND ranges?
Ironically this is used in ETSIs common lib code .. but so far no TTCN-3 tool has complained about it, i.e.,

type charstring AlphaNum ("0".."9","a".."z","A".."Z");

please enlighten me,
stephan

As per §6.1.2.5.1 of 'ETSI ES 201 873-1 V3.2.1 Part 1: TTCN 3 Core Language'

<<snip>>
Within charstring and universal charstring sub-type definitions it is not allowed to mix pattern, list or range constraints.
<<snip>>


o

---

o
Stephan Schulz, Ph.D.
ETSI - World Class Standards
Sr. Technical Expert
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
Tel: +33 49294 4964
Mobile: +33 63334 8269
Fax: +33 49365 4716
o

---

o

Hi Stephan,

I also have no clue why using patterns, range, and lists are not permitted.

From reading the standard, there is no clue or indication as to why the
restriction is present. It would be helpful to have
a short sentence explaining the restriction, and if there is no valid reason
from the restriction, then the "not" in the corresponding text should be
removed. There should be agreement from the tool providers and the user
community regarding this issue, as well as with the maintenance team.

NOTE> The text in 6.1.2.5.1 and BNF production 52. *STATIC SEMANTICS* are
not agreement with one another. The static semantics fails to mention the
use of pattern with list values and range as not being legal.

The mixing of single values, ranges of values and patterns may be related to
the difficulty of implementing such type
definitions, and then doing dynamic type checking at run time. this might
be especially time consuming when dealing
with universal charstring *with all those planes*. Creating a manageable
set of values might be a challenge... *well, might not be so difficult.
Just do a union of all the elements referenced in the sub type and ignore
the overlap, pattern
would require applying an intersection operator to determine the actual set
of values in the sub-type... Just a WAG...

example 2 in 6.1.2.5.1, shows only valid examples, no invalid examples.
Note, that these contain either, list, one range, or one pattern, but no
mixture of these. Adding an example of an invalid type definition would help
to explain the restriction.

The example you give in your mail is correct as you use 3 range values, and
no mixture of pattern, range, or list values. Try using something like:

type charstring AlphaNumPattern ("0", "1", "2", "a".."z","A".."Z", pattern
"[a-z]#(3,9)");

and see what happens. Per definition, this should fail. If it does not,
then one needs to think about either updating the standard or removing the
functionality from the tool you are using. Note that some tools might be
ignoring the subtyping definitions and simply allowing the base charstring
or universal charstring type as the actual type used during execution.
I doubt that most tools apply run-time bounds checking on everything. This
is not meant as a criticism, just that it is a fact of life...

NOTE> If you compare the text of the standard in part 1 873/201/1 V3.2.1,
where there is erroneous behaviour or an invalid
specification, there is usually a comment in the code explaining why the
example is invalid. generally though, I believe that there was much effort
placed in designing the standard so that positive instead of negative
examples are presented.

52. ValueOrRange ::= RangeDef | ConstantExpression
/* STATIC SEMANTICS - RangeDef production shall only be used with integer,
charstring, universal
charstring or float based types */
/* STATIC SEMANTICS - When subtyping charstring or universal charstring
range and values shall not
be mixed in the same SubTypeSpec */


Hope this helps.

Cheers,

Claude.



On 14/12/2007, Stephan Schulz <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
>
> Hi,
>
> does anyone (especially from the TTCN-3 standard maintanence team) know
> WHY charstring subtyping does not allow combinations of value lists AND
> ranges?
> Ironically this is used in ETSIs common lib code .. but so far no
> TTCN-3 tool has complained about it, i.e.,
>
> type charstring AlphaNum ("0".."9","a".."z","A".."Z");
>
> please enlighten me,
> stephan
>
> As per* §6.1.2.5.1 of 'ETSI ES 201 873-1 V3.2.1 Part 1: TTCN 3 Core
> Language'*
>
> <<snip>>
> Within charstring and universal charstring sub-type definitions it is not
> allowed to mix pattern, list or range constraints.
> <<snip>>
>
> o

---

o
> Stephan Schulz, Ph.D.
> ETSI - World Class Standards
> Sr. Technical Expert
> 650 Route des Lucioles
> F-06921 Sophia Antipolis Cedex
> Tel: +33 49294 4964
> Mobile: +33 63334 8269
> Fax: +33 49365 4716
> o

---

o
>
>



--
Blue Cactus Consulting
Edinburger Strasse 39
13349 Berlin
Germany
Phone: +49 (0) 30 9606 7985
Fax: +49 (0) 30 9606 7987
Mobile: +49 (0) 174 701 6792
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

Hi Stephan,

I think Thomas is right with his guess about pattern - I also think that it is rather about not mixing pattern on one hand side and value lists and ranges on the other hand side ... sounds like a CR is needed.

Cheers, Ina.


________________________________

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 Thomas Deiss
Sent: Friday, December 14, 2007 3:35 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Reasons for string subtyping?


Hello Stephan,

a couple of comments:

Actually I do not know where this restriction comes from, hence I can only speculate. I think the different handling of mixing subtyping for integers and charstrings might come from the different meaning of ranges for integers and charstrings. For integers a range can be seen as a shorthand for a lengthy value list. For charstrings it means to restrict the range of letters. Hence
type charstring Lower ("a".."z")
denotes the strings build from lowercase letters.
In contrast a value list defines some strings. Mixing range and value list notation for charstrings can be seen as providing at the same time information on some strings and on the characters that can be used for all strings. But as said, this is only speculation.

Regarding patterns: this _might_ be excluded as pattern are strictly more expressive that ranges and value lists and then two different mechanisms for the same problem would be used.

I suggest that you replace the specific subtype restriction in the ETSI common lib code by a corresponding pattern. Then you would be on the safe side.

And in case you feel that removing this restriction would ease the use of the language, I guess you have to write a CR :-)

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 Stephan Schulz
Sent: Friday, 14. December 2007 12:43
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Reasons for string subtyping?


Hi,

does anyone (especially from the TTCN-3 standard maintanence team) know WHY charstring subtyping does not allow combinations of value lists AND ranges?
Ironically this is used in ETSIs common lib code .. but so far no TTCN-3 tool has complained about it, i.e.,

type charstring AlphaNum ("0".."9","a".."z","A".."Z");

please enlighten me,
stephan

As per §6.1.2.5.1 of 'ETSI ES 201 873-1 V3.2.1 Part 1: TTCN 3 Core
Language'

<<snip>>
Within charstring and universal charstring sub-type definitions it
is not allowed to mix pattern, list or range constraints.
<<snip>>


o

---

o
Stephan Schulz, Ph.D.
ETSI - World Class Standards
Sr. Technical Expert
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
Tel: +33 49294 4964
Mobile: +33 63334 8269
Fax: +33 49365 4716
o

---

o

Hi all,

The issue is not so simple. First, mixing value list and ranges. Thomas is absolutaly rigth, the reason for forbidding value lists and ranges in the same subtype lists is that they semantically meaning something different.

The pattern and range subtyping is a different issue. They are not 100 % compatible! Think about ASN.1 permitted alphabet and pattern subtypings. While permitted alphabet is PER-visible and will determine the number of bits used to encode a character, pattern subtyping is not! So, in some cases a range subtyping will result different message encoding than a pattern subtyping (producing the same set of allowed abstract values). But, not in the case of the IP lib, so in that specific case range can be replaced by pattern (so it may have effect on the encoders/decoders). Btw. such cases was the reason that I proposed to check standard TTCN-3 codes with 3-4 different tools...

BR, Gyorgy

PS:
Claude wrote: "NOTE> The text in 6.1.2.5.1 and BNF production 52. *STATIC SEMANTICS* are not agreement with one another. The static semantics fails to mention the use of pattern with list values and range as not being legal."

No, it does not fails. Simply pattern cannot be produced from ValueOrRange, list+range and pattern subtypings are separated earlier, in the production of AllowedValues.


51. AllowedValues ::= "(" (ValueOrRange <outbind://26/#TValueOrRange> {"," ValueOrRange <outbind://26/#TValueOrRange> }) | CharStringMatch <outbind://26/#TCharStringMatch> ")"

52. ValueOrRange ::= RangeDef <outbind://26/#TRangeDef> | ConstantExpression <outbind://26/#TConstantExpression>

/* STATIC SEMANTICS - RangeDef production shall only be used with integer, charstring, universal charstring or float based types */

/* STATIC SEMANTICS - When subtyping charstring or universal charstring range and values shall not be mixed in the same SubTypeSpec */


________________________________

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 Schieferdecker, Ina
Sent: Saturday, 15 December, 2007 6:55 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Reasons for string subtyping?


Hi Stephan,

I think Thomas is right with his guess about pattern - I also think that it is rather about not mixing pattern on one hand side and value lists and ranges on the other hand side ... sounds like a CR is needed.

Cheers, Ina.


________________________________

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 Thomas Deiss
Sent: Friday, December 14, 2007 3:35 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Reasons for string subtyping?


Hello Stephan,

a couple of comments:

Actually I do not know where this restriction comes from, hence I can only speculate. I think the different handling of mixing subtyping for integers and charstrings might come from the different meaning of ranges for integers and charstrings. For integers a range can be seen as a shorthand for a lengthy value list. For charstrings it means to restrict the range of letters. Hence
type charstring Lower ("a".."z")
denotes the strings build from lowercase letters.
In contrast a value list defines some strings. Mixing range and value list notation for charstrings can be seen as providing at the same time information on some strings and on the characters that can be used for all strings. But as said, this is only speculation.

Regarding patterns: this _might_ be excluded as pattern are strictly more expressive that ranges and value lists and then two different mechanisms for the same problem would be used.

I suggest that you replace the specific subtype restriction in the ETSI common lib code by a corresponding pattern. Then you would be on the safe side.

And in case you feel that removing this restriction would ease the use of the language, I guess you have to write a CR :-)

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 Stephan Schulz
Sent: Friday, 14. December 2007 12:43
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Reasons for string subtyping?


Hi,

does anyone (especially from the TTCN-3 standard maintanence team) know WHY charstring subtyping does not allow combinations of value lists AND ranges?
Ironically this is used in ETSIs common lib code .. but so far no TTCN-3 tool has complained about it, i.e.,

type charstring AlphaNum ("0".."9","a".."z","A".."Z");

please enlighten me,
stephan

As per §6.1.2.5.1 of 'ETSI ES 201 873-1 V3.2.1 Part 1: TTCN 3 Core
Language'

<<snip>>
Within charstring and universal charstring sub-type definitions it
is not allowed to mix pattern, list or range constraints.
<<snip>>


o

---

o
Stephan Schulz, Ph.D.
ETSI - World Class Standards
Sr. Technical Expert
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
Tel: +33 49294 4964
Mobile: +33 63334 8269
Fax: +33 49365 4716
o

---

o