Issue 14639: OCL 2.1 Loop iterators are not ordered and other inconsistencies (ocl2-rtf) Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies. Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators. Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read. Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection. Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection. Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection. Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator. Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection. Figure 10.7 shows LoopExpEval.iterators as unordered 1..n. Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables". Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2. Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2. Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2. Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator. The above suggests that the specification should consistently treat iterators as having a 1..2 {ordered} multiplicity. Resolution: Revised Text: Actions taken: November 15, 2009: received issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FANo3/0rUnw4R/2dsb2JhbACCHzCYEbcPhDwE Date: Sun, 15 Nov 2009 07:07:38 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: issues@omg.org Subject: OCL 2.1 Loop iterators are not ordered and other inconsistencies X-Plusnet-Relay: 35dc9f01149cc956bac706fb863c0b28 Hi The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies. Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators. Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read. Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection. Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection. Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection. Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator. Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection. Figure 10.7 shows LoopExpEval.iterators as unordered 1..n. Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables". Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2. Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2. Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2. Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator. The above suggests that the specification should consistently treat iterators as having a 1..2 {ordered} multiplicity. Regards Ed Willink X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoGAAPtA0vUnw4U/2dsb2JhbACCJCyRTYR4gTC+UIQ7BA Date: Wed, 18 Nov 2009 20:48:42 +0000 From: Ed Willink User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: ocl2-rtf@omg.org Subject: Re: issue 14639 Loop iterators are not ordered and other inconsistencies X-Plusnet-Relay: 7614b1370d0ca6ddf90af92f9734a062 Hi Simple resolution bringing consistency by making LoopExp.iterator ordered. Regards Ed Willink 14639-OrderedLoopIterators.odt