Issue 19204: Specify the utility of an extent (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Clarification Severity: Minor Summary: There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility. The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object. MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller. Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent? Resolution: Specify the utility of an extent There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility. The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object. MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller. Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent? Discussion A section on Extents is sadly lacking; write it. The confusing fiction that there is a correspondence between QVTo Model Parameters and QVTr Domains is best eliminated. Revised Text: Add the following section after 8.1.2 Model Types and before 8.1.3 Libraries 8.1.x Extents, Models and Model Parameters The inputs and output of a transformation are identified by Model Parameters which have a direction, model name and ModelType. transformation Uml2Rdbms(in uml:UML, out rdbms:RDBMS) 8.1.x.1 Implementation responsibilities A transformation is executed by a QVTo implementation which must load an external model for each in and inout parameter and identify a future external model for each out parameter. When the transformation completes successfully, the implementation must save the inout models and the no longer future out models. 8.1.x.2 Extents The interface between implementation and specified behavior uses a distinct MOF Extent associated with each Model Parameter. A MOF Extent identifies the root objects of its Model. The root objects are members of the Extent and are said to reside in the Extent. The initial members of in and inout Extents are the roots of loaded external models. There are no initial members of out Extents. Each Extent for an in Model Parameter is immutable. It may be shared when the same external model is loaded by multiple in Model Parameters. Other Extents are mutable and must be distinct even when the same external model is bound to more than one Model Parameter. There are therefore no shared model conflicts within the QVTo engine. Resolution of the conflict between multiple Extents that need to be saved to the same external model is a problem for the implementation to solve, perhaps by prohibiting the conflict in the first place. 8.1.x.3 Models A Model comprises a forest of model elements (objects) with each tree defined by MOF containment relationships. For many applications, a single root, and its containment tree, rather than a forest is sufficient. However during the course of a transformation, model elements are created for use by the model and these may form additional roots until the model elements are assigned to their intended container. Each Model Parameter has an Extent whose members are the root objects of a Model. The ModelParameter's ModelType identifies the permitted content of the Model, The ModelParameter's name may be used with the operations of the Model library type. uml.objectsOfKind(Class); The name may be used to assign all members of the Extent. rdbms := aModel.copy(); A model assignment displaces any previous members associated with the extent in favor of the root model elements of the replacement Model. The previous members cease to reside in any Extent and so become orphans. Additional Models and corresponding Extents may be created by the Model::copy() and Model::createEmptyModel() operations. These Extents have no associated external model and so their contents will be lost unless assigned to Extents with external models or unless passed to other transformations. The Models passed to nested transformation calls by Transformation::transform() or Transformation::parallelTransform() may not be modified after the call. This may require that a copy is created. 8.1.x.4 Object Containment and Extent Residence A MOF object can be contained by at most one other object, consequently the containment relationship of a model form a forest. The roots of the forest have no containers, rather they are members of at most one Extent and are therefore said to reside in that Extent. The non-roots of the forest are transitively contained by a root that is a member of the Extent; the non-roots are therefore also said to reside in the Extent. Objects that do not reside in an Extent are orphans. parent.child := firstChild; // firstChild contained by parentparent.child := secondChild; // secondChild contained by parent, displaced firstChild is a root object Assignment of a container relationship, or opposite containment relationship, establishes a new parent-child containment relationship. This may displace the previous child so that it has no container, however the displaced child retains its residence in its models' extent; the displaced child is therefore added to the extent's members and is an additional root object for the model. model.addElement(anObject); // anObject resides in model Similarly assignment of the residence of a root object, establishes or updates the residence of the root object and transitively of all its contained objects. Any previous residence is eliminated. When a transformation consistently assigns all residences and containments for all objects, the result is often a tree for the Extent of each inout and out parameter. However if any residence or containment is left unassigned, some orphan objects are lost. Direct object creation or construction typically results in orphans whose containment and residence is assigned later since there is no inference of a default residence. The object may be explicitly assigned to the root of some extent when it is created: column := new Column@mymodel(n,t); // mymodel is the extent for the new instance.object x:X@srcmodel { ? } // x is created within the ?srcmodel? Objects returned as out or inout parameters of a mapping are assigned to an explicit or inferred extent. If no extent can be inferred, typically because two ModelParameters use the same ModelType, the objects are orphans. This is a programming hazard that can be diagnosed by tooling. An object may be completely removed from its extent by invoking Model::removeElement(). This makes the object an orphan with no references to or from any other object. Cloned and deepcloned objects are added to the Extent of the source object; they are therefore new root objects until assigned to some container. 8.1.x.5 Orphans An orphan is a potentially lost object; it resides in no container and no extent and so will not contribute to any out or inout model. Orphans may arise as the result of: *Model::removeElement() explicitly orphaning an object *model assignment displacing an obsolete model *non-mapping object construction Creation of orphans by object construction is discouraged in two ways. An @extent may form part of the ObjectExp, or Mapping out parameter declaration. In the case of mappings, a default extent is inferred by metamodel compatibility. However objects constructed within helpers may be orphans. An orphan may cease to be an orphan when a container is assigned, or when Model::addElement() is used to add the orphan element to the members of the Extent that identifies the root objects of the Model. Although an orphan may have no container and may reside in no extent, it may still be referenced by objects that reside in an out extent. At the end of the transformation, when out extents are saved, out extents referencing orphans are not well-formed since the orphans are missing; the saved extent is incomplete and difficult to use. Practical implementations may assist diagnosis of the bad result by rescuing the referenced orphans as members of one or more extents or providing an additional lifeboat output model. In 8.2.1.6 replace More precisely there is a MOF extent corresponding to each parameter. by More precisely each ModelParameter has a ModelType for a MOF Extent whose members are the root objects of the corresponding Model. In 8.2.1.6 delete the following contradiction Any object creation occurs in an extent associated with a model parameter. In 8.2.1.6 delete the following (rewritten above) Relationship between MOF extents and model parameters When a model element is created by a transformation it is necessary to know in what model the model element is to be created. In particular, this makes it possible to use the inspection operations on model parameters like objects() and objectsOfType() to retrieve an object previously created. In MOF there is a notion of Extent that is simply defined as a container for Objects. Here we are correlating the notion of model (represented by model parameters in a transformation definition) with the notion of MOF extent stating that for each model parameter there is a MOF extent. In 8.2.1.16 delete the following fiction A mapping operation being a refinement of a relation, a mapping parameter is associated with a domain of the refined relation. This correspondence is based on the order of the declared parameters and domains, where the contextual parameter, if any, is the first and the result parameters are positioned after the ?regular? parameters. The type of the mapping parameter should necessarily be the same as the type specified by the object pattern of the domain (see Domain definition in Clause 7.11). In 8.2.1.24 ObjectExp add after the first paragraph Object creation, initialization and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization always occurs, but may be trivial if the body is empty. Object residence is left unchanged when the extent is omitted; it will be established as soon as the created object is put at the target end of some composition relationship. An explicit object residence may be established by specifying the model parameter for the required extent as the extent. In 8.2.2.12 UnlinkExp correct An unlink expression represents an explicit removal of a valuean object from a multivalued property link. In 8.2.2.12 UnlinkExp add The residence of the removed object is unaffected. If the unlink affects a containment relationship, the no longer contained object becomes a root object of its model. If total removal is required the Model::removeElement() operation may be used. In 8.3.4 correct 8.3.4 Operations on elementsElements In 8.3.4.10 clone add The returned object is added to the root of the model containing the source element. In 8.3.4.11 deepclone add The returned object is added to the root of the model containing the source element. In 8.3.5 correct 8.3.5 Operations on modelsModels In 8.3.5.1 correct Returns the listset of theall objects in the model extent. In 8.3.5.3 correct Returns the set of all the objects in the extentmodel that are not contained by other objects of the extentin the model. Before 8.3.5.4 removeElement add 8.3.5.x addElement Model::addElement (anObject : Element): Void The object is first displaced from any usage by setting its container to null, then the object is added to the model's extent so that it provides another root for the model. Any non-containment references to and from the object are unaffected. In 8.3.5.4 removeElement replace Removes an object of the model extent. All links between the object and other objects in the extent are deleted. References from collections to the ends of deleted links are removed. References from noncollections are set to null. by Removes an object from the model so that it becomes an orphan. All references to or from the object are eliminated. References from collections are removed. References from non-collections are set to null. In 8.3.5.6 copy replace Performs a complete copy of a model into another model. All objects belonging to the source extent are copied into the target extent. by Creates a deep copy of a model and its extent. All objects transitively contained in the source model are copied into the new model. The roots of the new model are the initial members of the new extent. The new extent has no associated external file and so the new contents may be lost unless assigned to another model or passed to another transformation. In 8.3.5.7 createEmptyModel replace Creates and initializes a model of the given type. This operation is useful when creating intermediate models within a transformation. by Creates a model and extent of the given type without any content. This operation is useful when creating intermediate models within a transformation. Actions taken: February 5, 2014: received issue December 22, 2015: Resolved March 29, 2016: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 05 Feb 2014 06:12:22 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: 8 FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: n/a Title: Specify the utility of an extent Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:26.0) Gecko/20100101 Firefox/26.0 Time: 06:12 AM Description: There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility. The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object. MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller. Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent?