Issue 14434: File unique id is not useable (mtt-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: In section 7.3, the file block of the MOF model to text transformation language is detailed. This section introduces the "uniqId" attribute of the file blocks which is meant to allow a tool to find back a generated file even if the object from which it's been generated changed significantly since the last generation. Though this is a good thing in theory, such an ID cannot be implemented whatever the programming language chosen. Or rather, it cannot be implemented in a satisfying way. Let's assume we have this file block : [file ('c:/'.concat(class.name).concat('.c'), false, class.id)] So a file "class.c" will be generated at the root of disk c. Now I change my module so that now, the file block resembles this : [file ('d:/generated/'.concat(class.name).concat('.c'), false, class.id)] The class itself hasn't changed one bit; so both the file name (class.c) and its id (class.id) remain constant. How can the tool find back that a file has already been generated for such an ID? The tool itself cannot keep a reference to all files it has generated along with their IDs and locations; the possibility that we're generating files under version control and that others can generate the same on their own machines forbids this. The solution would then be to save the file _along with its ID_, thus breaking the WYSIWYG assumption of the specification as unwanted information would show up in the generated file. And even like that, the tool would need to lookup throughout the whole file system of the target in order to try and find a file which ID is the same as what we need to generate. With the current computers, that could mean searching within terabytes of data in order to find a file that might not even exist in the first place, and that for each [file] block of a generation module. I believe this unique ID is a good idea in theory, yet seeing as this idea cannot be implemented as more than an idea, I think all references to an ID should be removed from 7.3 (description of the file block), 8.1 (metamodel), 8.1.17 (file block's attributes) and 8.2 (concrete syntax). Resolution: Revised Text: Actions taken: September 28, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 28 Sep 2009 05:36:52 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Laurent Goubet Company: Obeo mailFrom: laurent.goubet@obeo.fr Notification: Yes Specification: MOF Model to Text Transformation Language (MOFM2T) Section: 7.3, 8.1, 8.1.17, 8.2 FormalNumber: formal/2008-01-16 Version: 1.0 RevisionDate: 01/16/08 Page: 9, 10, 13, 19, 22 Title: File unique id is not useable Nature: Revision Severity: Significant test: 3qw8 B1: Report Issue Description: In section 7.3, the file block of the MOF model to text transformation language is detailed. This section introduces the "uniqId" attribute of the file blocks which is meant to allow a tool to find back a generated file even if the object from which it's been generated changed significantly since the last generation. Though this is a good thing in theory, such an ID cannot be implemented whatever the programming language chosen. Or rather, it cannot be implemented in a satisfying way. Let's assume we have this file block : [file ('c:/'.concat(class.name).concat('.c'), false, class.id)] So a file "class.c" will be generated at the root of disk c. Now I change my module so that now, the file block resembles this : [file ('d:/generated/'.concat(class.name).concat('.c'), false, class.id)] The class itself hasn't changed one bit; so both the file name (class.c) and its id (class.id) remain constant. How can the tool find back that a file has already been generated for such an ID? The tool itself cannot keep a reference to all files it has generated along with their IDs and locations; the possibility that we're generating files under version control and that others can generate the same on their own machines forbids this. The solution would then be to save the file _along with its ID_, thus breaking the WYSIWYG assumption of the specification as unwanted information would show up in the generated file. And even like that, the tool would need to lookup throughout the whole file system of the target in order to try and find a file which ID is the same as what we need to generate. With the current computers, that could mean searching within terabytes of data in order to find a file that might not even exist in the first place, and that for each [file] block of a generation module. I believe this unique ID is a good idea in theory, yet seeing as this idea cannot be implemented as more than an idea, I think all references to an ID should be removed from 7.3 (description of the file block), 8.1 (metamodel), 8.1.17 (file block's attributes) and 8.2 (concrete syntax).