Issue 10936: 9.18 Undefined semantics (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: The whole Concrete Syntax section deserves a much more substantial description. In particular... The mechanism by which a package name is located is unresolved, perhaps deliberately, but the omission should be explicit. What constraints exist on forward referencing of names? Transformations and mappings could be ordered so that forward references are avoided, but large modules benefit from an alphabetical ordering of elements, so requiring a parser friendly order is not user friendly. Resolution: 9.18 Undefined semantics The whole Concrete Syntax section deserves a much more substantial description. In particular... The mechanism by which a package name is located is unresolved, perhaps deliberately, but the omission should be explicit. What constraints exist on forward referencing of names? Transformations and mappings could be ordered so that forward references are avoided, but large modules benefit from an alphabetical ordering of elements, so requiring a parser friendly order is not user friendly. Discussion This isn't going to happen until a QVT 2.0 rewrite adopts the autogeneration approaches underway for OCL. Revised Text: Actions taken: March 25, 2007: received issue December 22, 2015: Deferred March 29, 2016: closed issue Discussion: It is hard to tackle this properly until we have the model-driven specification generated technology that OCL 2.5 will pioneer. Specifically the specification defines a fixed point truth with little regard as to how this may be achieved. The direction of references is therefore irrelevant. Disposition: Deferred End of Annotations:===== s is issue # 10936 From: "Ed Willink" 9.18 Undefined semantics The whole Concrete Syntax section deserves a much more substantial description. In particular... The mechanism by which a package name is located is unresolved, perhaps deliberately, but the omission should be explicit. What constraints exist on forward referencing of names? Transformations and mappings could be ordered so that forward references are avoided, but large modules benefit from an alphabetical ordering of elements, so requiring a parser friendly order is not user friendly.