Issue 12950: No way to represent type parameters in the standard library (ocl2-rtf) Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com) Nature: Clarification Severity: Summary: Summary: The OCL metamodel does not provide means to encode type parameters in operations like the generic ones that are defined by Collection type in the standad library. Resolution: Adding a TemplateParameterType. This promotes the solution to this problem as found in QVT. Revised Text: (1) In Section 8.2, just before 8.2.1, add the definition: TemplateParameterType A TemplateParameterType is used to refer to generic types in parameterized definitions. It is used in the standard library to represent the parameterized collection operations. A template parameter type is usually named "T" (or "T2", "T3" and so on, when more than one type parameter is involved). The TemplateParameterType is a sub-class of Classifier. Attributes: specification : String An un-interpreted opaque definition of the template parameter type. Note: The definition should be placed in line with alphabetical order. (2) Update Figure 8.1 with the inclusion of the TemplateParameterType class. (3) In Section 13.3 Diagrams (Essential OCL), update the diagram (In this case, TemplateParameterType is a sub-class of Type). Actions taken: October 10, 2008: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== From: "Christian W. Damus" To: ocl2-rtf@omg.org Subject: Re: issues 12950 - 12952 -- OCL 2 RTF issues Date: Fri, 10 Oct 2008 15:24:00 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: Re: Issue #12950 Perhaps we can "promote" the QVT model of type parameters to OCL. Re: Issue #12951: The Eclipse OCL implementation adopts the SQL convention of escaping a single-quote in a string literal by repeating it. e.g., 'This string literal isn''t invalid' This is fairly intuitive and doesn't open the door to other escapes, as a backslash might do. Also, there is the question of escaping spaces in element names. The Eclipse implementation uses the double-quote character for this, as some SQL dialects do. e.g., context Department inv: not self.employee->exists(oclIsKindOf(Companies::"Contract Employee")) There is not, currently, any problem of double-quotes in String literals, as strings are delimited by single-quotes. Thoughts? Christian On 10-Oct-08, at 1:48 PM, Juergen Boldt wrote: From: This is issue # 12950 No way to represent type parameters in the standard library Summary: The OCL metamodel does not provide means to encode type parameters in operations like the generic ones that are defined by Collection type in the standad library. ===================================================================== This is issue # 12951 Use of MOF reflection in EssentialOCL should be clarified Summary: There is no clear indication weather MOF reflection is available in EssentialOCL (except in the provided xmi, ecore files of essential ocl). ====================================================================== This is issue # 12952 Use of simple quotes and double quotes in strings Summary: Use of simple quotes in place of double quotes should be allowed, Specially in situations where the string contains double quotes (to avoid explicit use of escaping characters). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com m: This is issue # 12950 No way to represent type parameters in the standard library Summary: The OCL metamodel does not provide means to encode type parameters From: "Christian W. Damus" To: ocl2-rtf@omg.org Subject: Re: Additional resolution proposals Date: Sat, 18 Oct 2008 09:43:10 -0400 X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s014.panelboxmanager.com X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zeligsoft.com X-Source: X-Source-Args: X-Source-Dir: Hi, Mariano, Thanks for taking these issues on! I have a few general comments: The title page references "OCL 2.1 XMI files." Are there XMIs for the 2.0 version? They don't seem to be available on the OMG website The RTF membership list has Zeligsoft's member and organization names reversed On specific issues: >>> 12583 "OCL 2.0 8.2 Real" Agreed. >>> 12944 "Type of a type expression" Agreed. Let us ensure that the resolution of 9171 clearly indicates that the type of the Type Expression is not the referred type, as suggested by the issue's submitter, but the Classifier metaclass. >>> 12945 "Missing definition of iterators for OrderedSets" The definitions look good. However, the signatures of all but the select iterator are incomplete. The others should be indicated as: reject(expression : OclExpression) : OrderedSet(T) collectNested(expression : OclExpression) : Sequence(T) sortedBy(expression : OclExpression) : OrderedSet(T) >>> 12946 re: missing OrderedSet operations Agreed. >>> 12947 "Clarify the common supertype of Bag and Sequence" Agreed. Also, the resolution text has two occurrences of "sentence" that should be "sequence." >>> 12948 "Making OclAny denote any object" The phrase "that complies with all the types" does not make sense to describe the AnyType metaclass. It is OclAny that should be described as a type to which all other types conform. Perhaps we can replace the AnyType definition with: AnyType is the metaclass of the special type OclAny, which is the type to which all other types conform. OclAny is the sole instance of AnyType. A distinct metaclass is required to define the special property of being the generalization of all other Classifiers, including Classes, DataTypes, PrimitiveTypes. In the replacement text for (3) in Section 11.2.1, I think "conform to" is more consistent terminology than "comply with." >>> 12950 "No way to represent type parameters in the standard library" How are instances of the TemplateParameterType to be owned? I would expect a package such as the Standard Library to have multiple instances named "T" with different semantics indicated by the specification property. If that is the case, then it seems that they would need to have distinct owners. In the UML, parametered elements are generally owned by the classifiers or operations that expose them. I suppose that OCL can define a composite association on CollectionType for the type parameter T of its elementType, but for Operations (as imported from UML) it may be more difficult. We can define a composite end owned by the association that is nonetheless navigable, but I'm not sure that it works well with XMI ... >>> 12951 "Use of MOF reflection in EssentialOcl should be clarified" Agreed. It might be beneficial, also, to add a statement to the effect that reflection is provided by the oclIsKindOf(), oclIsTypeOf(), and oclType() operations (the latter upon adoption of the proposal for Issue 9171). >>> 12952 "Use of simple [sic] quotes and double quotes in strings" Agreed. We should make sure that Issue 8789 adequately deals with single quotes in string literals; I am not sure that the current proposal does (I shall endeavour to amend it). Cheers, Christian On 17-Oct-08, at 1:00 PM, wrote: -- Christian W. Damus Senior Software Developer, Zeligsoft Inc. Component Lead, Eclipse MDT OCL and EMF-QTV E-mail: cdamus@zeligsoft.com in operations like the generic ones that are defined by Collection type in the standad library.