|
Notes |
|
|
(0008997)
|
|
Gyorgy Rethy
|
11-09-2009 12:08
(edited on: 11-09-2009 12:16) |
|
CR5340_resolution_Px_v1.doc: first drafts for the resolution for part-1, 7 and 9.
Open: how to handle exclusive range boundaries of constrained float types?
1) introduce exclusive boundaries in TTCN-3 as well (CR5344)
2) refer to some " minimal distinguishable real value", that is a) platform dependent; as the converter and the TTCN-3 tool may be used on different platforms, this may lead to different behaviours of different TTCN-3 tools b) not as exact as TTCN-3 should be.
3) define the "minimal distinguishable real value"; the real behaviour of tools still may be platform dependent and in some specific cases behaviours of all tools may be wrong (if the received value less by delta than the boundary but this delta is less than the "minimal distinguishable real value";
|
|
|
|
|
|
Ready for review. Solution relies upon the new exclusive boundary feature in the core for float, double and decimal types. Mapping of integer do not change. Also handling of date/time types is added, though the bounding facets applied to date/time types are ignored (but this is explicit now). Also text is extended to cover the different cases more precisely and explicitly, though technical change effects only the float/double/decimal types. |
|
|
|
|
For sake of simplicity, I propose to use also for XML one rule for handling of exclusive boundaries and not to differentiate between float and integer types for that, i.e.
Instead of
<simpleType name="e12a">
<restriction base="positiveInteger">
<maxExclusive value="100"/>
</restriction>
</simpleType>
// Is mapped in TTCN-3 to:
type XSD.PositiveInteger E12a (1 .. 99)
with {
variant "name as uncapitalized"
}
we may define
<simpleType name="e12a">
<restriction base="positiveInteger">
<maxExclusive value="100"/>
</restriction>
</simpleType>
// Is mapped in TTCN-3 to:
type XSD.PositiveInteger E12a (1 .. !100)
with {
variant "name as uncapitalized"
}
The proposals for Part 1 and Part 7 are ok. |
|
|
|
|
|
Implemented in Part-9, according to Ina's proposal on the unified handling of integer and float/double types. |
|
|
|
|
|
Implemented in Part-7 acc. to CR5340_resolution_P7_v4.doc. |
|
|
|
|
Part 1 changes implemented with minor changes:
In 7.1.3: "minus zero is less than plus zero, which represents zero"
In 6.1.1: "NOTE 2: - not_a_number (i.e. minus not a number) is not to be used."
In BNF:
FloatValue ::= FloatDotNotation | FloatENotation | NaNKeyword
--> FloatValue without InfinityKeyword as this is already part of the range definition |
|
CR5340_resolution_P1_v3.doc (259,072) 11-12-2009 09:22