Issue 13265: Page 65, Notation Section 8.2.1.3 Module (qvt-rtf) Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody) Nature: Revision Severity: Minor Summary: Problem's text: "configuration property UML::Attribute::MAX_SIXE: String discussion: providing a context to a configuration property doesn't seem to make sense. suggestion remove "UML::Attribute::" Resolution: It's not obviously sensible, but is it actually wrong? If there are many configuration properties, it may be convenient to partition them hierarchically. cf. java.vm.specification.vendor. The punctuation is however confusing; add a space. Revised Text: In 8.2.1.1 OperationalTransformation change Properties that are configuration properties are declared using the configuration qualifier keyword. configuration property UML::Attribute::MAX_SIZE: String; to Properties that are configuration properties may have hierarchical scope. They are declared using the configuration qualifier keyword. configuration property UML::Attribute::MAX_SIZE : String; Actions taken: January 15, 2009: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== s is issue # 13265 Page 65, Notation Section 8.2.1.3 Module Problem's text: "configuration property UML::Attribute::MAX_SIXE: String discussion: providing a context to a configuration property doesn't seem to make sense. suggestion remove "UML::Attribute::" X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KvrD2AmN c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=jRaRe28YeiwA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=Czs2y7CAOUAA:10 a=8ld4rXT9AP8vd2LTltUA:9 a=Joz6bFBnuaggJ8gi:21 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 Date: Fri, 31 Jan 2014 10:51:52 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: "qvt-rtf@omg.org" Subject: Issue 13265 : Configuration property qualification X-Virus-Scanned: amavisd-new at omg.org Hi In "Re: Issue 19021: Inconsistent description about constructor names." Adolfo commented on Issue 13265: Let me throw a couple of questions: - What does "hierarchical scope" of a configuration property mean? - How does this "hierarchical scope" get reflected in the abstract syntax ? - Which is the owner of this configuration property ? a) The transformation ? b) UML::Attribute ? - Which is the qualified name of such a property, for instance, to access its value? a) MyTransformation::MAX_SIZE ? b) UML::Attribute::MAX_SIZE ? c) MyTransformation::UML::Attribute::MAX_SIZE ? [Suggestion: Reconsider the issue suggestion] This is an area where I have minimal expertise, so my initial response was based rather on intuition. Now after some study: It seems that in the EBNF there is only a keyword spelling difference between a configuration and an intermediate property. It seems that in the AST there is only a relationship spelling (and source derivation) difference between a configuration and an intermediate property. Therefore the resolution, which does not create the requested intermediate/configuration property, seems right. Suggestions for clearer wording welcome. ----- However: "Which is the owner of this configuration property" This has the easy answer: the owner of the equivalent intermediate property. For new classes this is solvable, OperationalTransformation.nestedPackage owns the package and so the class and so the property; but what are the URIs for such intermediates? For existing classes such as in UML::Attribute::extravalue, we need an ability to extend UML::Attribute which neither QVTo nor UML provide. In 8.1.9. we have The important point is that intermediate properties are manipulated as ordinary properties of the context metaclass (UML::Class in our example). But if they are ordinary we expect intermediateProperty.container() to be the extended class rather than the OperationalTransformation. Perhaps we need to raise an issue to leverage the required OCL 2.5 solution for extensible classes for Complete OCL. ------ Returning to the issue 8.1.9 Intermediate properties are property extensions that do not exist outside the scope of the transformation that defines it. 8.2.1.1 The population of configuration properties may be done using any external mechanism; for instance, using an external configuration file. This aspect is beyond the scope of this specification. So it seems that the difference is that - intermediate properties are 100% internal and mutable. - configuration properties are externally definable and immutable. Both can be arbitrarily located in the metamodels. I see no reason why a configuration property should not be scoped so that it is accessible as if it were a (static readonly) property of UML::Attribute as in 8.2.1.1 configuration property UML::Attribute::MAX_SIZE : String; Regards Ed Willink X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=rIvGu+jhDMP/GxY2mPbyZqTgbt+KzzwhRnTfgf6EC5Q=; b=IOx3L+lClMT9FceeaUmyjlg4HB4N7WwNBRqhXFFvF0fMjKLze+ZP3792Wl0Uro2x4c HvV4FortnfaPW3H7FlVpIR1E4/M6jH4no4ksfr1tdSeOnaupH6uiQNBABDJZvIQKMvGj i20Rw5SQK4vxYIlCCfx8AzqSOIlkTgdAJUZgOqRIcOBEhT/k/f9qvr7C0x1fmHqU9Sls 1HYD2EG4z7fVx+FJKz4WdMi3e6KdJMQAXxW4/PtMt/8zyJQAk+U11ARft2qXLuzByq0M btkLLmwjXca6CnjWs1BS+YbXjccoNAZmd5OfnDvBesLkAczaKc2oENQHS6Pk4+IoJO8B zjTg== X-Gm-Message-State: ALoCoQkL8zSkPjMO3ZsQSHjZJxDRHwdON9M/t/q12tEY9MLXIehhw5fuwhaXbZMka9jK0c34i3iN X-Received: by 10.15.45.194 with SMTP id b42mr2041876eew.103.1391169227856; Fri, 31 Jan 2014 03:53:47 -0800 (PST) Sender: Adolfo Sanchez Barbudo Date: Fri, 31 Jan 2014 11:53:39 +0000 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 To: "qvt-rtf@omg.org" Subject: Issue 13265. X-Virus-Scanned: amavisd-new at omg.org Hi Ed, I had written a long email, explaining what intermediate and configuration properties are. That explanation is at the end of the email in the TL;DR version. After thinking more about this. I can see an option to improve the specification and making room for the suspicious example and not introducing the vague "hierarchical scope" concept: Combining both configuration and intermediate keywords. I previously saw configuration properties, only as configuration properties of the transformation. Now, I see that the configuration keyword could enhance "intermediate properties" so that the initial value may be passed from the transformation caller. This idea is aligned with the abstract syntax point of view, since OperationalTransformation::intermediateProperty and OperationalTransformation::configurationProperty are non-containment associations. It also adds a more powerful vision about these configuration properties make them extensible to intermediate properties. The current concrete syntax definition also supports the idea. What about the following resolution? : In 8.2.1.1 Replace: An operational transformation may define configuration properties, that is, properties that actual value is to be given at execution time. In addition it may define intermediate data properties and define explicitly new classes to store intermediate data. By: An operational transformation may define intermediate data properties and define explicitly new classes to store intermediate data. In addition it may define configuration properties, that is, properties that actual value is to be given at execution time. Note that intermediate data properties might be configuration properties at the same time (see examples in the notation section). Replace: configuration property UML::Attribute::MAX_SIZE: String; by -- an own transformation configuration property configuration property DEBUG : Boolean; An intermediate property could be used with the configuration keyword denoting that property initial value may be given at execution time -- an UML::Attribute intermediate and configuration property intermediate configuration property UML::Attribute::MAX_SIZE : String; Regards, Adolfo. P.S: BTW, I agree with the other suggestions you did to other issues resolution I sent. Well spotted. -------- TL;DR ------ My issue resolution pretentiously suggested that "UML::Attribute" is surplus. My suspicious was that it came from a copy-paste from the intermediate property from two lines above in the specification: "intermediate property UML::Attribute::extravalue : String;" Intermediate properties are additional properties defined on existent classifiers, so the "UML::Attribute" prefix for "extravalue" makes sense, because we are defining an additional intermediate property on an UML::Attribute. Configuration properties are properties of the transformation with the aim of passing additional values (usually, primitive values) to the transformation from the invoker. Therefore, they are properties which belong to the transformation and they only need a name and a type. Specifying another classifier as prefix doesn't make sense, and it should be an error. X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KvrD2AmN c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=oCcaPWc0AAAA:8 a=-cyFu3I6LbHlj7IwMsgA:9 a=wPNLvfGTeEIA:10 Date: Fri, 31 Jan 2014 12:12:43 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: "qvt-rtf@omg.org" Subject: Re: Issue 13265. X-Virus-Scanned: amavisd-new at omg.org Hi your response seems to have missed my message on 13265 an hour earlier where I raised serious issues about the AS practicality. Could you revise your AS suggestions to agree/disagree with my concerns. Your idea of allowing 'intermediate configuration' seems to add nothing; rather it confuses. IMHO an intermediate property is mutable and a configuration property is immutable. An 'intermediate configuration property' is therefore a contradiction. Regards Ed Willink On 31/01/2014 11:53, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, I had written a long email, explaining what intermediate and configuration properties are. That explanation is at the end of the email in the TL;DR version. After thinking more about this. I can see an option to improve the specification and making room for the suspicious example and not introducing the vague "hierarchical scope" concept: Combining both configuration and intermediate keywords. I previously saw configuration properties, only as configuration properties of the transformation. Now, I see that the configuration keyword could enhance "intermediate properties" so that the initial value may be passed from the transformation caller. This idea is aligned with the abstract syntax point of view, since OperationalTransformation::intermediateProperty and OperationalTransformation::configurationProperty are non-containment associations. It also adds a more powerful vision about these configuration properties make them extensible to intermediate properties. The current concrete syntax definition also supports the idea. What about the following resolution? : In 8.2.1.1 Replace: An operational transformation may define configuration properties, that is, properties that actual value is to be given at execution time. In addition it may define intermediate data properties and define explicitly new classes to store intermediate data. By: An operational transformation may define intermediate data properties and define explicitly new classes to store intermediate data. In addition it may define configuration properties, that is, properties that actual value is to be given at execution time. Note that intermediate data properties might be configuration properties at the same time (see examples in the notation section). Replace: configuration property UML::Attribute::MAX_SIZE: String; by -- an own transformation configuration property configuration property DEBUG : Boolean; An intermediate property could be used with the configuration keyword denoting that property initial value may be given at execution time -- an UML::Attribute intermediate and configuration property intermediate configuration property UML::Attribute::MAX_SIZE : String; Regards, Adolfo. P.S: BTW, I agree with the other suggestions you did to other issues resolution I sent. Well spotted. -------- TL;DR ------ My issue resolution pretentiously suggested that "UML::Attribute" is surplus. My suspicious was that it came from a copy-paste from the intermediate property from two lines above in the specification: "intermediate property UML::Attribute::extravalue : String;" Intermediate properties are additional properties defined on existent classifiers, so the "UML::Attribute" prefix for "extravalue" makes sense, because we are defining an additional intermediate property on an UML::Attribute. Configuration properties are properties of the transformation with the aim of passing additional values (usually, primitive values) to the transformation from the invoker. Therefore, they are properties which belong to the transformation and they only need a name and a type. Specifying another classifier as prefix doesn't make sense, and it should be an error. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7047 - Release Date: 01/30/14