Issue 13180: section (8.3.2) is very confusing for the reader (qvt-rtf) Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody) Nature: Clarification Severity: Minor Summary: his section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing. Resolution: section (8.3.2) is very confusing for the reader This section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing. Discussion - Ocl type prefixes As an OCL user, I find the attempt and recommendation to hide the underlying OCL functionality very confusing, particularly when it introduces potential collisions whose prevention is inaccurately described. Since the description of the M1 types does not enumerate them, I am not clear which types are intended. If Eclipse QVTo is any guide, it would be OclAny/Any, OclVoid/Void, but not OclElement, OclInvalid, OclMessage, OclState, OclType. If this policy is to remain recommended, it must also apply to all of the above. I find the injection of Element and Type into the user's namespace particularly offensive. I recommend that the recommendation be reversed, so that we just observe that QVTo implementations offering backward compatibility may permit the seven enumerated synonyms to be used as shortforms of the full spelling. Discussion - ocl operation prefixes The references to the "Ocl" prefix are inaccurate for operations where it is "ocl". As an OCL user, I find the attempt and recommendation to hide the underlying OCL functionality a bit confusing, particularly since the abbreviated forms are used very little used in the editorial text and have no definition. I recommend eliminating their editorial usage and defining them as synonyms that a QVTo implementation offering backward compatibility may support as an alternate spelling that is mapped to the full spelling when used within the abstract syntax Discussion - Operation name synonyms This section was written for OCL 2.0 which has no String::+ operator. String::+ is available in OCL 2.4 so there is no need for QVT 1.2 to define it as a synonym.The other mathematical operators have always been part of OCL, so the purpose of enumerating them is unclear and indeed confusing. Is there actually an operation with the spelling "operator+"? I see no need for one. In the concrete syntax, "+" is fully available. In UML and OCL "+" is a permissible internal spelling for an operation name. The _'+' escape enables its use in arbitrary name contexts. The only question is whether a particular implementation might choose to use "plus" as a spel;ling to avoid problems in languages that do not allow arbitrary spellings. But that is an implementation language-specific choice that does not affect QVT or OCL; perhaps relevant to the Java-binding for OCL specification if written. FWIW, Eclipse QVTo has no "operator+" operation. Conversely, is the specification actually saying that "plus" may be used rather than "+"? This might be a way of elevating an implementation language workaround into the source, which seems rather perverse. FWIW, Eclipse QVTo provides no "divide" operation. The operation synonym sentences can be eliminated without any loss. Revised Text: In 8.1.14, 8.1.15, 8.2.2.6, A.2.3 replace isKindOf by oclIsKindOf. In 8.1.14, 8.2.12, 8.2.13, 8.2.15 replace isTypeOf by oclIsTypeOf. In A.2.3 replace asType by oclAsType In 8.3.2. Replace All the OCL operations starting with ?Ocl? prefix have a synonym operation in the QVT library where the prefix is skipped. For instance: isKindOf is a synonym of oclIsKindOf. All the predefined OCL types M1 starting with ?Ocl? prefix have a synonym type in the QVT library where the prefix is skipped. The Ocl prefix in types and operations, can still be used but its usage is not recommended since name conflicts can be avoided by qualifying with the name of the library (StdLib). by QVT 1.0, 1.1 and 1.2 encouraged the use of the simpler "asType", "isKindOf" and "isTypeOf" synonyms for "ocl"-prefixed operation names such as "oclAsType", "oclisKindOf" and "oclIsTypeOf" . Use of "Any" and "Void" synonyms were similarly encouraged in preference to "Ocl"-prefix types such as "OclAny" and "OclVoid". Since these synonyms may introduce conflicts and since few QVTo users can avoid also being OCL users, the use of these synonyms is deprecated. A QVTo implementation may support these deprecated synonyms by translating them to their prefixed form before using them in any Abstract Syntax representation. Any conflicting usage of the synonyms must ignore the synonym in favor of the user declaration. Delete The following synonyms are defined for the following pre-defined OCL operations: String : operator+ -> concat Integer: operator+ -> plus, operator- (binary) -> minus, operator- (unary) -> unaryminus operator* -> multiply operator/ -> divide Real: operator+ -> plus, operator- (binary) -> minus, operator- (unary) -> unaryminus operator* -> multiply operator/ -> divide Actions taken: December 19, 2008: received issue December 22, 2015: Resolved March 29, 2016: closed issue Discussion: Once OCL 2.5 provides an extensible modeled OCL Standard Library, there will be no need for this to be more than additional library definitions. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 19 Dec 2008 13:53:24 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Adolfo Sanchez-Barbudo Herrera Company: Open Canarias S.L. mailFrom: adolfosbh@opencanarias.com Notification: Yes Specification: MOF 2.0 QVT Section: 8.3.2 FormalNumber: formal/2008-04-03 Version: 1.0 RevisionDate: 04/03/08 Page: 108 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; es-ES; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Description his section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing.