ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0004850 | Part 01: TTCN-3 Core Language | Technical | public | 13-02-2009 11:49 | 26-02-2009 21:16

Reporter | Thomas DeiÃŸ |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.1.1 (published 2009-06) | Fixed in Version | v4.1.1 (published 2009-06) |
Clause Reference(s) | part1, 6.2., 7.1.3
Source (company - Author) | Jacob Wieland, Testing Tech.

Summary | 0004850: type compatibility of union does not coincide with union equality

Description

reported by Jacob Wieland on draft of edition 4.1:
I have a problem with the type compatibility of union types vs. the equality of union values in the current draft of the core language standard.
As I understand it, a union type A is compatible to another union type B (meaning expressions of A can be used as expressions of B, I presume), if all its variants are also present in B - WITH THE SAME NAMES.
In the section on relational operators, it is stated, that two union values that can be equal need not have the same variant names, just compatible types for 'counterparts' variants, (I guess, counterpart means the variant at the same place in the union types, judging from the examples, maybe this should be clarified further, as well).
This means that two values of incompatible types can be equal in the case of unions. In my understanding, though, it is normally only allowed for compatible types to apply the comparison operators to. This seems to be a kind of contradiction or at least inconsistency, which could lead to a lot of confusion.
Therefore, I would propose to either
- change the union type compatibility in such a way that the existent comparison operator semantics can be applied, (i.e. by ignoring the field names and just regarding the order of the fields) OR
- change the equality so that it is consistent with compatibility, i.e.
the type of one of the compared values must be compatible with the type of the other one (which means the variants must be equally named and typed, but not in the same order, as I understand it), thereby getting equal union values if the variant with the same name is chosen in both and the variant values of both are equal.
Although I like the second variant more, because I like the concept of union type compatibility that has been proposed, the change COULD cause backward incompatibilities in those cases where the current feature of name-independence and order-dependence for equality of union values was used. This is a question that should be asked if anyone knows of a test suite where this feature was used (which I actually doubt, cause it is a very strange definition of union equality in the first place).
Therefore, I would vote for option 2, i.e. keeping the proposed type compatibility and changing the equality semantics.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0004508 | closed | Ina Schieferdecker | type compatibility of relational operators

Attached Files

Resolution CR_4850.doc (158,208) 16-02-2009 11:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2001&type=bug
Resolution CR_4850_r1.doc (153,600) 16-02-2009 16:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2002&type=bug
Resolution CR_4850_r2.doc (155,136) 18-02-2009 08:29
http://oldforge.etsi.org/mantis/file_download.php?file_id=2004&type=bug
Resolution CR_4850_r3.doc (159,744) 20-02-2009 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2009&type=bug
Resolution_CR_4850_r4.doc (176,640) 20-02-2009 14:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2010&type=bug
Resolution_CR_4850_r5.doc (178,688) 20-02-2009 16:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=2011&type=bug
Resolution_CR_4850_r6.doc (259,072) 26-02-2009 09:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=2015&type=bug
Resolution_CR_4850_r7.doc (265,728) 26-02-2009 14:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2016&type=bug
Resolution_CR_4850_r8.doc (271,360) 26-02-2009 15:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2017&type=bug

Issue History
Date Modified | Username | Field | Change
13-02-2009 11:49 | Thomas DeiÃŸ | New Issue |
13-02-2009 11:49 | Thomas DeiÃŸ | Status | new => assigned
13-02-2009 11:49 | Thomas DeiÃŸ | Assigned To | => Ina Schieferdecker
13-02-2009 11:49 | Thomas DeiÃŸ | Clause Reference(s) | => part1, 6.2., 7.1.3
13-02-2009 11:49 | Thomas DeiÃŸ | Source (company - Author) | => Jacob Wieland, Testing Tech.
13-02-2009 11:50 | Thomas DeiÃŸ | Note Added: 0008098 |
13-02-2009 12:49 | Thomas DeiÃŸ | Target Version | => Edition 4.1.1 (not yet published)
16-02-2009 05:46 | Ina Schieferdecker | Note Added: 0008102 |
16-02-2009 05:47 | Ina Schieferdecker | Resolution | open => fixed
16-02-2009 05:47 | Ina Schieferdecker | Status | assigned => resolved
16-02-2009 05:47 | Ina Schieferdecker | Fixed in Version | => Edition 4.1.1 (not yet published)
16-02-2009 05:49 | Ina Schieferdecker | Relationship added | related to 0004508
16-02-2009 05:50 | Ina Schieferdecker | Status | resolved => closed
16-02-2009 09:47 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Thomas DeiÃŸ
16-02-2009 09:47 | Gyorgy Rethy | Status | closed => feedback
16-02-2009 09:47 | Gyorgy Rethy | Resolution | fixed => reopened
16-02-2009 09:47 | Gyorgy Rethy | Note Added: 0008106 |
16-02-2009 10:25 | Thomas DeiÃŸ | Note Added: 0008108 |
16-02-2009 10:26 | Thomas DeiÃŸ | Assigned To | Thomas DeiÃŸ => Gyorgy Rethy
16-02-2009 10:26 | Thomas DeiÃŸ | Status | feedback => assigned
16-02-2009 10:26 | Thomas DeiÃŸ | Resolution | reopened => open
16-02-2009 10:29 | Ina Schieferdecker | Note Added: 0008109 |
16-02-2009 10:29 | Ina Schieferdecker | Note Edited: 0008109 |
16-02-2009 11:54 | Gyorgy Rethy | Note Added: 0008111 |
16-02-2009 11:55 | Gyorgy Rethy | File Added: Resolution CR_4850.doc |
16-02-2009 16:31 | Ina Schieferdecker | File Added: Resolution CR_4850_r1.doc |
18-02-2009 08:29 | Thomas DeiÃŸ | File Added: Resolution CR_4850_r2.doc |
20-02-2009 12:41 | Ina Schieferdecker | File Added: Resolution CR_4850_r3.doc |
20-02-2009 14:37 | Gyorgy Rethy | File Added: Resolution_CR_4850_r4.doc |
20-02-2009 14:46 | Gyorgy Rethy | Note Added: 0008167 |
20-02-2009 16:23 | Gyorgy Rethy | File Added: Resolution_CR_4850_r5.doc |
20-02-2009 16:28 | Gyorgy Rethy | Note Added: 0008171 |
24-02-2009 07:44 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
26-02-2009 09:22 | Gyorgy Rethy | File Added: Resolution_CR_4850_r6.doc |
26-02-2009 09:29 | Gyorgy Rethy | Note Added: 0008201 |
26-02-2009 14:16 | Gyorgy Rethy | File Added: Resolution_CR_4850_r7.doc |
26-02-2009 14:18 | Gyorgy Rethy | Note Added: 0008203 |
26-02-2009 15:58 | Gyorgy Rethy | File Added: Resolution_CR_4850_r8.doc |
26-02-2009 15:59 | Gyorgy Rethy | Note Added: 0008204 |
26-02-2009 21:15 | Ina Schieferdecker | Status | assigned => resolved
26-02-2009 21:15 | Ina Schieferdecker | Resolution | open => fixed
26-02-2009 21:16 | Ina Schieferdecker | Status | resolved => closed

Notes

(0008098)
Thomas DeiÃŸ
13-02-2009 11:50

Discussion so far (email thread):
Hello Gyorgy,
Regarding this case 3: when checking the definition of equality again, I recognized that we avoided a general statement to require that equality can be applied to values of compatible types only. We defined equality type by type. Therefore we could also allow to compare arbitrary union values. Result in this specific case 3 would be false. Gyorgy, your proposal is then fine for me.
I have added a specific proposal below:
Current text in clause 7.1.3
Two values of union types are equal if, and only if, the effective value structures of the union types are compatible, the selected fields in both values are the counterparts to each other, the types of the chosen fields are compatible and the actual values of the chosen fields are equal
New proposal:
Two values of union types are equal if, and only if, the both values are compatible with the type of the other value, the same alternative has been selected in both values, and the actual values of the chosen fields are equal.
Best regards
Thomas
>-----Original Message-----
>From: ext GyÃ¶rgy RÃ©thy [mailto:gyorgy.rethy@ericsson.com]
>Sent: Thursday, 12. February 2009 11:39
>To: Deiss, Thomas (NSN - DE/Duesseldorf); Schieferdecker, Ina; ext Jens
>Grabowski
>Cc: Jacob Wieland
>Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
>
>Hi Thomas,
>
>In case 3) I would also always return false. Shortly, we are comparing
>two values, u1 and u2. If the name of the selected alternative in both
>values are the same AND the types of the selected alternatives are the
>same (enumerated), compatible (structured types) or has the same root
>type (basic types), comparision returns true, otherwise false.
>
>I think it would an unnecessary complication to separate the case type
>union U1( integer a }; type union U2{integer a, integer b } from the
>case type union U1( integer a }; type union U3{integer c, integer b }
>
>We also do allow comparing values of these integer subtypes, though it
>is clear that they do not have a common subset, thus comparision can
>never be true:
>type integer I1 (0..2); type integer I2 (3..5);
>
>BTW. if the assignment in the example below could be reached, it would
>cause test case error... but it can never be reached:
>var I1 i1; var I2 i2;
>... //some values are allocated to i1 and i2 if (i1 == i2) {i1 := i2}
>
>BR, Gyorgy
>
>
>> -----Original Message-----
>> From: Deiss, Thomas (NSN - DE/Duesseldorf)
>> [mailto:thomas.deiss@nsn.com]
>> Sent: 2009-februÃ¡r-12 11:07
>> To: GyÃ¶rgy RÃ©thy; Schieferdecker, Ina; ext Jens Grabowski
>> Cc: Jacob Wieland
>> Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
>>
>> Hello Gyorgy,
>>
>> So, if there are two union types U1 and U2, and two values u1 and u2
>> of type U1 and U2 respectively, then there are three cases:
>>
>> 1) If u1 is compatible with U2 and u2 is compatible with U1, then
>> comparison is possible and if the same alternative is selected and
>> holds the same value the result will be true, otherwise false.
>> 2) If either u1 is compatible with U2 or u2 is compatible with U1,
>> the comparison is allowed, but would always result in false.
>> 3) If neither u1 is compatible with U2 nor u2 is compatible with U2,
>> then this would be an error.
>>
>> Did I get your proposal correctly?
>> If so, then this would be fine from my side.
>>
>> Best regards
>>
>> Thomas
>>
>> >-----Original Message-----
>> >From: ext GyÃ¶rgy RÃ©thy [mailto:gyorgy.rethy@ericsson.com]
>> >Sent: Wednesday, 11. February 2009 09:50
>> >To: Deiss, Thomas (NSN - DE/Duesseldorf); Schieferdecker,
>> Ina; ext Jens
>> >Grabowski
>> >Cc: Jacob Wieland
>> >Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
>> >Importance: High
>> >
>> >Hi Thomas,
>> >
>> >Your example will never fail with my union compatibility
>> proposal! Once
>> >the equality is true, in both values the same alternatives
>> are chosen
>> >and the asignment will be successful.
>> >What I propose is, in fact, that the comparision "u1 == u2"
>> >should not cause test case error; it should return false
>> instead (thus
>> >the assignment does not get control);
>> >
>> >As I wrote, I can see the situation here to be similar to e.g.
>> >subtyped integers. See the examples:
>> >type integer MyInt1 (0..1);
>> >type integer MyInt2 (1..3);
>> >type integer MyInt3 (2..3);
>> >...
>> >var MyInt1 int1; var MyInt2 int2; var MyInt3 int3; ...
>> >int1 := int2; // may fail if int2 <> 1
>> >int1 := int3; // will fail for sure
>> >int3 := int1; // will fail for sure
>> >if(int1 == int2) {int1 := int2; int2 := int1} //will never fail
>> >if(int1 == int3) {int1 := int3; int3 := int1} //will never
>> fail, just
>> >the body of the if stmt. never executed
>> >
>> >I fact, looking at these examples, compatibility of (the
>> >complete) union types should never be controlled at
>> comparision, just
>> >the compatibility of the selected alternatives (name and
>field_type)
>> >and always return false or true.
>> >
>> >BR, Gyorgy
>> >
>> >> -----Original Message-----
>> >> From: Deiss, Thomas (NSN - DE/Duesseldorf)
>> >> [mailto:thomas.deiss@nsn.com]
>> >> Sent: 2009-februÃ¡r-11 8:31
>> >> To: GyÃ¶rgy RÃ©thy; Schieferdecker, Ina; ext Jens Grabowski
>> >> Cc: Jacob Wieland
>> >> Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for Edition 4.1.1
>> >>
>> >> Hello Gyorgy,
>> >>
>> >> In my opinion, type compatibility and equality should be
>> defined such
>> >> that for two union variables u1, u2 of two different
>types U1, U2,
>> >> the following code never fails in the assignment.
>> >> if (u1 == u2) {
>> >> u1 := u2;
>> >> ...
>> >> Additionally, whereever u1 can be used in an operation or
>> expression
>> >> it is possible to use u2. This includes the usage of ischosen(),
>> >> which could be used to check whether a different
>> alternative than the
>> >> currently chosen one has been chosen.
>> >>
>> >> This implies that the definition of equality is
>> symmetrical, I think
>> >> that just requiring that one union type is compatible with
>> the other
>> >> is not sufficient.
>> >>
>> >> Note that this property does not hold for record values
>> (fieldnames
>> >> are not considered in the check for equality), hence the strict
>> >> definition above would be different to the definition of
>> equality of
>> >> other types.
>> >>
>> >> Best regards
>> >>
>> >> Thomas
>> >>
>> >> >-----Original Message-----
>> >> >From: ext GyÃ¶rgy RÃ©thy [mailto:gyorgy.rethy@ericsson.com]
>> >> >Sent: Tuesday, 10. February 2009 16:16
>> >> >To: Deiss, Thomas (NSN - DE/Duesseldorf); Schieferdecker,
>> >> Ina; ext Jens
>> >> >Grabowski
>> >> >Cc: Jacob Wieland
>> >> >Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for
>Edition 4.1.1
>> >> >Importance: High
>> >> >
>> >> >Dear all,
>> >> >
>> >> >we also do support Jacob's proposal, i.e. option two,
>namely that
>> >> >compatibility of union values shall be based on equal field
>> >> name and a
>> >> >compatible value.
>> >> >
>> >> >But this second condition raises another question:
>> >> >compatibility of union types, where the alternatives of
>> one of the
>> >> >types (call it A) is a subset of the alternatives in the
>> >> another type
>> >> >(call it B). In this case, a value of A could always be
>> >> assigned to an
>> >> >instance of B, i.e. A is compatible with B. This is fine in
>> >> the case of
>> >> >assignment( & alike) operations, but may cause problems in
>> >> the case of
>> >> >comparision (being defined as a symmetrical operation).
>> >> >
>> >> >What to do if a value of A (which is compatible with B) is
>> >> compared to
>> >> >an instance of B in which the selected alternative is
>> >outside of the
>> >> >common subset? Error or false? Error could be the principal
>> >> answer but
>> >> >false would be the practical one.
>> >> >I feel this case to be similar to the case of comparing two
>> >subtyped
>> >> >integers, where the value sets of their types do not have
>> a common
>> >> >subset. Thus, I would say, if at least one of the union
>values is
>> >> >compatible to the type of the other value, comparision
>> >should return
>> >> >false in the above case.
>> >> >
>> >> >If you think this is a realistic use case, as one may want
>> >> to restrict
>> >> >the alternatives used in one message and allow the broader
>> >> selection in
>> >> >another message. As we do not have extensibility for
>> types, the way
>> >> >today is to define two - compatible - types (strictly for
>> >> matching it
>> >> >could be enough to define a base value set template, but
>> >> this approach
>> >> >would fail at the first case when the message or the union
>> >> field has to
>> >> >be passed as parameter).
>> >> >
>> >> >BR, Gyorgy
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Deiss, Thomas (NSN - DE/Duesseldorf)
>> >> >> [mailto:thomas.deiss@nsn.com]
>> >> >> Sent: 2009-februÃ¡r-10 7:50
>> >> >> To: Schieferdecker, Ina; ext Jens Grabowski; GyÃ¶rgy RÃ©thy
>> >> >> Subject: FW: [MTS-GEN] Approval of TTCN-3 drafts for
>> Edition 4.1.1
>> >> >>
>> >> >> Good morning together,
>> >> >>
>> >> >> Jacob raised an issue on compatibility of union types and
>> >> equality of
>> >> >> union values. I agree with Jacob's proposal to define
>> >equality for
>> >> >> two union values if the same alternative (indicated by
>> >the name of
>> >> >> the alternative) and the same value is chosen. As usual,
>> >values of
>> >> >> compatible union types can be compared against each other,
>> >> they have
>> >> >> the same alternatives and that the alternatives are defined
>> >> >> identically.
>> >> >>
>> >> >> But this implies that there is a backwards incompatible
>> >> change, see
>> >> >> the example on equality of union values in clause
>> 7.1.3. With the
>> >> >> definitions above, some of the equal values would no
>> >> longer be equal.
>> >> >>
>> >> >> What do you think, should we go for this change. If yes,
>> >> then I could
>> >> >> ask the tool vendors whether they are aware of any test
>> >> suite where
>> >> >> this would be a problem, and if ok propose the specific
>> >> text. If no,
>> >> >> then we probably should weaken the definition of type
>> >> compatibility
>> >> >> of union values such that it corresponds to this example:
>> >> Two union
>> >> >> types are compatible if they have the same number of
>> >alternatives,
>> >> >> and in the order of the definition, the types of the
>> >> alternatives are
>> >> >> compatible. Names of alternatives would not be relevant at all.
>> >> >>
>> >> >> I would also prefer Jacobs proposal.
>> >> >>
>> >> >> Best regards
>> >> >>
>> >> >> Thomas
>> >> >>
>> >> >> PS: Sorry for disturbing in case you received similar
>> >> email already
>> >> >> yesterday, but I had some problems with sending to MTS-GEN
>> >> yesterday.
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: Deiss, Thomas (NSN - DE/Duesseldorf)
>> >> >> >Sent: Monday, 09. February 2009 10:11
>> >> >> >To: 'Jacob Wieland'; MTS-GEN@LIST.ETSI.ORG
>> >> >> >Subject: RE: [MTS-GEN] Approval of TTCN-3 drafts for
>> >Edition 4.1.1
>> >> >> >
>> >> >> >Hello Jacob,
>> >> >> >
>> >> >> >Thanks for pointing this out.
>> >> >> >
>> >> >> >Yes, there is actually an inconsistency between 6.3.2.4 Type
>> >> >> >compatibility of union types and 7.1.3. Relational Operators.
>> >> >> >
>> >> >> >I suggest also to use proposal 2). You are right, this
>> >would be a
>> >> >> >backward incompatible change. And you are also that the term
>> >> >> >'counterpart' in 7.1.3 leaves room for interpretation
>> >> (does it mean
>> >> >> >same name or same position in the definition).
>> >> >> >The example
>> >> >> > conUniD1 == conUniE1;
>> >> >> > // returns true
>> >> >> >suggests that it is 'same position in the definition',
>> >> >> independent of
>> >> >> >the name of the alternative. Again, this would contradict the
>> >> >> >definition of compatibility in clause 6.3.2.4.
>> >> >> >Taking compatibility as in clause 6.3.2.4, 'counterpart'
>> >> >> >should really mean that the same alternative (indicated
>> >> by the same
>> >> >> >name) is taken in both values.
>> >> >> >
>> >> >> >Best regards
>> >> >> >
>> >> >> >Thomas
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>-----Original Message-----
>> >> >> >>From: MTS_Gen [mailto:MTS-GEN@LIST.ETSI.ORG] On Behalf Of
>> >> >ext Jacob
>> >> >> >>Wieland
>> >> >> >>Sent: Thursday, 05. February 2009 16:02
>> >> >> >>To: MTS-GEN@LIST.ETSI.ORG
>> >> >> >>Subject: Re: [MTS-GEN] Approval of TTCN-3 drafts for
>> >> Edition 4.1.1
>> >> >> >>
>> >> >> >>Hello folks,
>> >> >> >>
>> >> >> >>I have a problem with the type compatibility of union
>> >> >types vs. the
>> >> >> >>equality of union values in the current draft of the
>> >> core language
>> >> >> >>standard.
>> >> >> >>
>> >> >> >>As I understand it, a union type A is compatible to another
>> >> >> union type
>> >> >> >>B (meaning expressions of A can be used as
>expressions of B, I
>> >> >> >presume),
>> >> >> >>if all its variants are also present in B - WITH THE
>> SAME NAMES.
>> >> >> >>
>> >> >> >>In the section on relational operators, it is stated, that
>> >> >> two union
>> >> >> >>values that can be equal need not have the same variant
>> >> >names, just
>> >> >> >>compatible types for 'counterparts' variants, (I guess,
>> >> >counterpart
>> >> >> >>means the variant at the same place in the union types,
>> >> >> judging from
>> >> >> >>the examples, maybe this should be clarified further,
>> as well).
>> >> >> >>
>> >> >> >>This means that two values of incompatible types can be
>> >> >> equal in the
>> >> >> >>case of unions. In my understanding, though, it is
>> >normally only
>> >> >> >>allowed for compatible types to apply the comparison
>> >> operators to.
>> >> >> >>This seems to
>> >> >> >>be a kind of contradiction or at least inconsistency, which
>> >> >> >could lead
>> >> >> >>to a lot of confusion.
>> >> >> >>
>> >> >> >>Therefore, I would propose to either
>> >> >> >>- change the union type compatibility in such a way that
>> >> >> the existent
>> >> >> >>comparison operator semantics can be applied, (i.e. by
>> >> >ignoring the
>> >> >> >>field names and just regarding the order of the fields) OR
>> >> >> >>- change the equality so that it is consistent with
>> >> compatibility,
>> >> >> >>i.e.
>> >> >> >>the type of one of the compared values must be
>> >> compatible with the
>> >> >> >>type of the other one (which means the variants must be
>> >> >> equally named
>> >> >> >>and typed, but not in the same order, as I understand it),
>> >> >> >thereby getting
>> >> >> >>equal union values if the variant with the same name is
>> >> >> >chosen in both
>> >> >> >>and the variant values of both are equal.
>> >> >> >>
>> >> >> >>Although I like the second variant more, because I like the
>> >> >> >concept of
>> >> >> >>union type compatibility that has been proposed, the
>> >> change COULD
>> >> >> >>cause backward incompatibilities in those cases where
>> >the current
>> >> >> >feature of
>> >> >> >>name-independence and order-dependence for equality of
>> >> >union values
>> >> >> >>was used. This is a question that should be asked if anyone
>> >> >> knows of a
>> >> >> >>test suite where this feature was used (which I actually
>> >> >> doubt, cause
>> >> >> >>it is a very strange definition of union equality in the
>> >> >> first place).
>> >> >> >>
>> >> >> >>Therefore, I would vote for option 2, i.e. keeping the
>> >> >> proposed type
>> >> >> >>compatibility and changing the equality semantics.
>> >> >> >>
>> >> >> >>Best regards,
>> >> >> >>
>> >> >> >>Jacob Wieland
>> >> >> >>
>> >> >> >>--
>> >> >>
>> >>---------------------------------------------------------------
>> >> >> >>----------
>> >> >> >>Jacob Wieland
>> >> >> >>Software Engineer
>> >> >> >>
>> >> >> >>Testing Technologies IST GmbH MichaelkirchstraÃŸe 17/18
>> >> >> >>10179 Berlin, Germany
>> >> >> >>
>> >> >> >>Phone +49 30 726 19 19 34 Email
>> >> >> wieland@testingtech.com
>> >> >> >>Fax +49 30 726 19 19 20 Internet
>> >> www.testingtech.com
>> >> >>
>> >>---------------------------------------------------------------
>> >> >> >>----------
>> >> >> >>
>> >> >> >>UPCOMING EVENTS
>> >> >> >>
>> >> >> >>February 5, Free TTCN-3 Webinar
>> >> >> >>TTCN-3 for Test Automation
>> >> >> >>www.testingtech.com/services/ttcn3_webinar.php
>> >> >> >>
>> >> >> >>February 16-19, 2009, Mobile World Congress Barcelona,
>> >> Spain, Hall
>> >> >> >>2.1, Booth #B77 www.mobileworldcongress.com/
>> >> >> >>
>> >> >> >>February 18, 2009, sepp.med Expertensymposium Deutschland,
>> >> >> >>Herzogenaurach www.seppmed.de/
>> >> >> >>
>> >> >>
>> >>---------------------------------------------------------------
>> >> >> >>----------
>> >> >> >>GeschÃ¤ftsfÃ¼hrung: Theofanis Vassiliou-Gioles,
>Stephan Pietsch
>> >> >> >>Handelsregister HRB 77805, Amtsgericht Charlottenburg Ust
>> >> >> ID Nr.: DE
>> >> >> >>813 143 070
>> >> >> >>
>> >> >> >>This e-mail may contain confidential and privileged
>> >> >> material for the
>> >> >> >>sole use of the intended recipient. Any review, use,
>> >> >> distribution or
>> >> >> >>disclosure by others is strictly prohibited. If you
>> are not the
>> >> >> >>intended recipient (or authorized to receive for the
>> >recipient),
>> >> >> >>please contact the sender by reply e-mail and delete all
>> >> copies of
>> >> >> >>this message.
>> >> >> >>
>> >> >>
>> >>
>> >>-------------------------------------------------------------------
>> >> >> >>Mail archive for MTS-GEN can be browsed at the
>> following url :
>> >> >> >> http://list.etsi.org/MTS-GEN.html [^]
>> >> >>
>> >>
>> >>-------------------------------------------------------------------
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>

(0008102)
Ina Schieferdecker
16-02-2009 05:46

7.1.3 corrected as proposed: "Two values of union types are equal if, and only if, both values are compatible with the type of the other value, the same alternative has been selected in both values, and the actual values of the chosen fields are equal."

(0008106)
Gyorgy Rethy
16-02-2009 09:47

Unfortunately the proposed text would require that the types of the two values are completely identical and does not specify what should happen if two values of incompatible types (or a value compatible with the type of the other value) is compared (false or error)?

(0008108)
Thomas DeiÃŸ
16-02-2009 10:25

Seems that the 'if and only if' is not sufficient... Requested cased expressed explicitly.
Two values of union types are equal if, and only if, both values are compatible with the type of the other value, the same alternative has been selected in both values, and the actual values of the chosen fields are equal. In case that the values are not compatible, a different alternative was chosen, or the actual values are different, the result shall be false.

(0008109)
Ina Schieferdecker
16-02-2009 10:29

An "if and only if" is content-wise expressive enough - I do not see a need to enumerate the other cases explicitly.

(0008111)
Gyorgy Rethy
16-02-2009 11:54

Pls. see my proposal for the text in the attached file.

(0008167)
Gyorgy Rethy
20-02-2009 14:46

Pls. find my additions in Resolution_CR_4850_r4.doc. Regarding the union stuff I have restored the sentence saying that comparing two union values shall not cause an error. It is important, as you can remember that the whole discussion on equality started with a mail on the TTCN-3 list (I think from Spain) asking, in which case comparision shall lead to error and in which case to false. So, it is important to be clear and explicit in this respect. Plus some editorials.
I also added a new subclause on anytype compatibility. It differs slightly from union compatibility as in anytype type names are used as field identifiers. But while the name of a built-in TTCN-3 type denotes the same type in each module, two types with the same name defined in different modules denoting different types, thus shall not be "the same field name".

(0008171)
Gyorgy Rethy
20-02-2009 16:28

One more change in version ~r5.doc. The "root" type has nothing to do with type compatibility, therefore referencing to effective structures and clause 6.3 in the definition of root type is not correct; this is relevant only when defining which types are compatible within the whole set of a root type (e.g. which records are compatible and one are not).
E.g.
type integer I1 (0..2);
type integer I2 (3..4);
are not compatible (not a single instance of I1 is compatible with I2 and vice versa), still they have the same root type.

(0008201)
Gyorgy Rethy
26-02-2009 09:29

Pls. note:
- I tried to apply the text proposed by Jens but did not copied it one-to-one.
- I also copied and reviewede all uses of "root" in Part-1. I highlighted them with yellow for your convenience only, no other meaning behind.
- I have also reviewed the definition of union type to remove inconsistency in the termilogy used in relation to unions and thus prevent misinterpretations.
Good reading!

(0008203)
Gyorgy Rethy
26-02-2009 14:18

~r7: - editorials are corrected, thank for the comments - three notes added, all of them are related to address; highlighted with blue background to make it easier to find them.

(0008204)
Gyorgy Rethy
26-02-2009 15:59

in ~r8: - Thomas's editorial comment is implemented - word comments are deleted