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.
