Issue 10946: Collection element type serialization (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: The OCL abstract syntax for Collections has no property to persist the element type of the collection. It is therefore not possible to serialise a TypeExp.referredType referring to for example OrderedSet(String) without synthesising an OrderedSet_String and finding some artificial scope for it .. and then encountering ambiguities as to whether two distinct OrderedSet_String types are really distinct. Suggest: Introduce a CollectionTypeExp extending TypeExp to add CollectionTypeExp.referredElementType : Type[0..1] with the constraint that the inherited TypeExp.referredType be a collection type. Resolution: Revised Text: Update Section 12.2 “The ExpressionInOcl Type” to add a new composite aggregation of Classifier, to provide for ownership of the generated types required by the body expression. Specifically, Update Figure 12.1 “Metaclass ExpressionInOcl” to show a composite aggregation between ExpressionInOcl (role name “owningExpression”, non-navigable) and Classifier (role name “generatedType”, composite, navigable) Update Section 12.2.1 “ExpressionInOcl”, subsection “Associations”, to add a description of the generatedType association end: Types, such as collection types, that are created on demand by OCL to serve as the types of OclExpressions in the bodyExpression. Update Section 8.2.2 “Well-formedness Rules for the Types Package” to remove the subsection “Classifier” with its one constraint stipulating the unique definition of collection types for a given element type. Actions taken: March 26, 2007: received issue October 16, 2009: closed issue Discussion: The submitter’s proposal does not address the problem of referencing nested collection types (collections of collections). Nor does it address other implicitly-generated types such as MessageTypes and TupleTypes. A more general solution is to provide, in the top-level constraint context, ownership of these types so that they can be serialized together with the constraint that depends on them. The assumption is that a namespace is not required for these types as they are artificial, anyway, and that replication of equivalent types in multiple constraints can be resolved by the OCL tool. Currently, OCL defines well-formedness rules for the Classifier metaclass stipulating that for every classifier, there is at most one instance of each of the four concrete collection types. It is not at all clear how this should relate to the Environment construct, or what the scope of allInstances() is, in practice. Moreover, it is not necessary to require this uniqueness of collection types because the conformance rules completely define the equivalence of collection types of the same kind and element type. An OCL tool may be given the freedom to replicate collection types for its own purposes, for example to ensure consistent serialization of expressions without compromising the OCL semantics. It is worth noting that no such uniqueness restriction is currently defined for the other dynamically-generated types, the TupleTypes and MessageTypes. End of Annotations:===== m: "Ed Willink" To: Cc: Subject: Collection element type serialization Date: Mon, 26 Mar 2007 20:52:31 +0100 X-Mailer: Microsoft Outlook, Build 10.0.6822 Thread-Index: Acdv4Eo+B+hMTc5FR+eVKSqrjh3www== X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org The OCL abstract syntax for Collections has no property to persist the element type of the collection. It is therefore not possible to serialise a TypeExp.referredType referring to for example OrderedSet(String) without synthesising an OrderedSet_String and finding some artificial scope for it .. and then encountering ambiguities as to whether two distinct OrderedSet_String types are really distinct. Suggest: Introduce a CollectionTypeExp extending TypeExp to add CollectionTypeExp.referredElementType : Type[0..1] with the constraint that the inherited TypeExp.referredType be a collection type. Regards Subject: Feedback on issues from 8663 to 12485 Date: Thu, 9 Oct 2008 16:04:37 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on issues from 8663 to 12485 thread-index: AckqF/bHnUBqNPt8Ry6DkAvW50hUEQ== From: To: X-OriginalArrivalTime: 09 Oct 2008 14:04:41.0376 (UTC) FILETIME=[F9688200:01C92A17] Hi all, Continuing with my feedback on the proposed resolutions, here is my feedback for the rest of the issues from Christian document (from 8663 to 12485) >>> Issue 8663: Section: 11.9.1 exists Agree (No change, misunderstanding) >>> Issue 8664: Section: 11.9.1 reject Agree (No change, misunderstanding) >>> Issue 8787: The spec does not describes the syntax of integer, real or string literals Agree (Adding some text in 9.3 Concrete Syntax section). >>> Issue 8790: OclAny cannot be an instance of Classifier Agree (Closed, Already resolved) >>> Issue 8818: Reusing TypedElement for UnspecifiedValueExp Agree (Closed, Already resolved) >>> Issue 10787: OCL Collections applied to Properties Agree (No change) >>> Issue 8917: allInstances Agree (Adjusting the description text of allInstances) >>> Issue 8937: Notation for accessing class operations is inconsistent Agree (clarifying allInstance is not static) >>> Issue 9171: Introduction and oclType() Strongly agree. But the exact wording of teh resolution will depend on resolution of issue 6532 Notice that EssentialOcl merges the reflection MOF capability. However its true that getMetaClass() is not applicable to the values of DataTypes since it returns a Class. >>> Issue 9405: Wrong subtyping of PropertyCallExp and NavigationCallExp Agree (clarifying why the subtyping is not wrong) >>> Issue 9796: Section: 7.3.4 Agree (Fixing usage of @pre) >>> Issue 9913: Section: 8.3.5 Agree (Adding the missing definitions in concrete syntax part). In fact the FTF, for timing reasons didn't touch the concrete syntax section which become somehow de-synchrnized with the rest. >>> Issue 10430: Section 7.6.3 Agree (Clarifying number of iterators in forAll). >>> Issue 10432: Section "IteratorExpCS" Agree (No change) >>> Issue 10433: 11.2.3 Agree. Good point. OclVoid cannot conform to OclInvalid. >>> Issue 10434: 11.2.4 (OclInvalid) - similar criticism as 11.2.3 Agree (same as previous). >>> Issue 10436: 11.2.5 Agree (description reformulation). Indeed replacement of OclType by Classifier depends on issue 6532. >>> Issue 10436: 11.2.5 (02) Agree (Re-typing to a supertype does not mean ability to access an overridden property). However still the question whether we allow access to an overriden property is pending. (available in various languages). This may be useful when defining the overriden version of an Operation. But for sure this should not use the oclAsType operator. Replacement of OclType by Classifier depends on issue 6532. >>> Issue 10825: ownership of association ends does not matter for traversal in OCL I think this issue is controversial. We should take care not to define behaviors that cannot be easily implemented. Also this may have an impact on reflection. Does it means that when we use the reflective MOF interface to look for attributes of a class we obtain also not owned Attributes? Any opinion, reacion here? >>> Issue 10921: TypeType This depends on resolution of issue 6532. >>> Issue 10946: Collection element type serialization Agree. Non uniqueness of collection types is important since it gives more freedom on where to place its definition. However, it is important to clarify that it is not mandatory to use the "generatedType" association to store the generated types. Depending on the context of usage, these generated types can also be created within a Package (using ownedType association). >>> Issue 11097: Dynamic typing with allInstances() I don't think I agree with all the text. I prefer the actual definition notation: allInstances() : Set( T ) Instead of allInstances() : Set( self ) Which is syntactically very hazardous. Now, making the allInstances be an operation of Classifier (the M1 instance representing the UML Classifier metatype) will be, for sure, consistent with the proposed resolution of 6532. So I think this depends on issue 6532. More specifically, I believe this kind of change should be part of resolution of 6532 and not be the resolution of this issue. The resolution for issue 11097 should then probably be: Closed, no change. >>> Issue: 11098: Section: 7.4.7, 7.4.9, 9.3.2 Agree (adding implies and let in operator priority definition). >>> Issue 12378: Section 8.2 InvalidType Agree. Terminology clarification. >>> Issue 12419: CollectionType and CollectionKind I believe the resolution is not complete. The example provided by the submitter of the issue shows that the CollectionType cannot be an abstract metaclass since the definition of a OCL constraint really requires instatiating CollectionTypes (Collection(Type) in the provided example). In fact a Collection is "abstract" from a runtime point of view, but not "abstract" from an OCL constraint definition point of view. But in practice this means that the M2 metaclass ColelctionType cannot be abstract. >>> Issue 12449: no explanations about how to manipulate optional and multivalued attributes Agree (Misunderstanding) >>> Issue 12450: The Tuple constructor is problematic Agree (Misunderstanding) >>> Issue 12484: Section 8.2.1 Type Conformance on page 37 Agree (already discussed) >>> Issue 12485: Section 8.2 page 35 InvalidType Agree (duplicated) Mariano Belaunde Senior Researcher in Modelling Techniques Orange Labs 8 Avenue Pierre Marzin 22300 Lannion France tel +33 2 96 05 30 85 mariano.belaunde@orange-ftgroup.com Ed Willink