Issue 1307: IDL Mapping/Identifier Naming (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Section 7.2.1, ppf 7-2. There is a section on name mangling which describes how a MOF name is mapped to an IDL name. The mapping definition provided has the following problems: * There can be any number of MOF names which map to a single identifier in IDL. A legal configuration of names in a MOF namespace may result in name conflicts when mapped to IDL. Section 7.4, p 7-33 states that the "IDL mapping may not produce valid CORBA IDL if ...preconditions on the input model is not satisfied:... the names within a NameSpace must be unique after application of the Format1 and Format2 name rewriting algorithms." * The name mangling is not based on any standard, but rather "stylistic conventions". * It is unnatural for a user to see different names in his MOF/UML model than in the corresponding IDL. * The IDL for MOF does not even follow the guidelines (see format for constants, ppf A-2, format for exceptions throughout document) * Some forms of identifier are not covered, such as enumeration value, structs, unions, discriminators. * Will need to add arcane mangling rules for object by value and other OMG specifications which extend IDL. Resolution: closed issue Revised Text: Actions taken: May 4, 1998: received issue May 8, 2000: closed issue Discussion: Discussion: Some name-mangling is inevitable, because any name in MOF (e.g. "thing" might have to be used to form a number of differerent names in IDL (e.g. ThingSet, Thing-Bag, ThingList). Immediately, the problem arises of whether there is already something called "ThingSet" etc. The other problem is that alignment with UML prevents putting MOF restrictions on names that cannot easily map to IDL (e.g. names containing spaces) or names that are also IDL reserved words. The problem is made doubly-difficult by the presence of concurrent RFPs that are likely to extend the list of reserved words. The issue of the reformating the names into format1 and format2 was based on the ORBOS style guide (the only "standard" available to us within the OMG at the time of the submis-sion) and perhaps might be revised in the light of the new style guide being prepared by Dan Franz. This approach was taken to produce a more "CORBA-natural" look-n-feel to the generated interfaces. Clearly, not everyone agrees with what is "natural" and perhaps we need a wider survey of CORBA programmers to gain a better understanding of what is "natural". The comments about some forms of identifier not being covered are correct as far as the ORBOS style guide is concerned, but this is already explicitly noted in the MOF spec and extensions to cover these types are given. If the IDL for MOF does not follow the formatting guidelines, then we should revise it so it does. This suggests that there is a difference between the MOF specifications and the MOF prototypes that were used to generate the IDL for the MOF spec. It would be possible to resolve the name-mangling problems by having a rule that if a gen-erated name would clash with an existing name (or IDL reserved word), then the generated name had some suffix (e.g. "_") repeatedly added until no clash would occur. We would generate some horrible names but they would be unique. However, to make this work, we would need an ordering rule over generation so we would know what names were gener-ated first (and hence what names were already in use). Orlando MOF-RTF resolution: We came up with three new proposals in the session. Proposal #1 add a set of aliases [multiplicity *, ordered] to ModelElement by either (a) extending the metamodel with an ?aliases? association from ModelElement, OR (b) using ALIAS tagged-value pair to hold aliases. Proposal #2 continue with existing IDL generation patterns, respecting the aliasing of pro-posal #1. When a generator identifies a conflict with a name, it should try the aliases that are associated with the ModelElement, in sequen-tial order, until there is no conflict. Proposal #3 We strongly urge IDL generators to leave behind a comment at any point in the IDL where aliasing (or name-mangling) has occurred, indicating the element?s origi-nal in the model, perhaps with a rationale for the name change. DSTC Response (crawley@dstc.edu.au) With the current MOF specification, if some choice of a ModelElement name leads to a name clash in the mapped IDL, the modeller always has the option of changing ModelEle-ment names. IMO it is unreasonable for the modeller to expect to choose ModelElement names without considring the consequences in the generated IDL. From this point of view, aliasing is an unnecessary and possibly harmful complexity. However, if we are going to add extra MOF functionality to support aliasing ... with the extra complexity that this entails ... Proposal #1 is a good idea, but needs more thought. Alternative a) is incomplete. What is the type/class of the other end of the "Aliases" association? Alternative b) is not a good idea. For aliasing to be acceptable, the MOF IDL mapping must continue to give equiva-lent IDL for equivalent meta-models. Unfortunately the way that the Tag model element has been defined it is not clear whether they should be used to change the meaning of a meta-model rather than extending the meaning. Aliases certainly DO change the meaning! At any rate, if aliases become a fundamental part of the MOF, they deserve to be a part of the meta-meta-model, not an "afterthought" handled by an ill-defined extension mecha-nism. I'd favour a very simple approach of adding extra attributes to ModelElement; for example attribute optional string preferred_name; which might give a single name to be used in place of the ModelElement name in all cases, or attribute ulist [0..*] of string alternative_names; which might give a set of alternatives to be used if the primary ModelElement name gives a name clash. (More about this below) Proposal #2 is nice in theory, but in practice it makes IDL generation a lot harder. Cur-rently, an IDL generator can simply generate according to the templates, and throw the IDL at a standard IDL compiler to validate it. Any name clashes are the modeller's prob-lem. With proposal #2, the IDL generator needs to know that IDL it would generate con-tains a name-clash. This entails building a symbol table for the IDL as it is generated, AND generating it in a particular order to get the substitutions to work correctly. Proposal #3 needs to be tempered with reality. Just about every identifier in the generated IDL is going to have been subjected to some form of name mangling. Generating masses of comments about name mangling etc is going to make the IDL unreadable. In practice, the name mangling rules used by the IDL mapping produces IDL that is highly readable and not needing comments. (New) Proposed resolutions: 1. Define a Tag name or names for Tags that allows a user to supply a substitute name for a given Model element in the IDL mapping. The simplest viable alternative is to supply a name that replaces the ME name prior to any name formatting and man-gling. Another alternative is to do pattern matching and replacement after name mangling based regular expressions supplied in a Tag for a model element. 2. Include recommendation that these Tags should be contained by the Package de-noting the meta-model. 3. Rule that the wider issue of name mangling in MOF is beyond the scope of the RTF. Implementation: Added text for 1 and 2 in Section 5.6.2, “Tags for providing substi-tute identifiers,” on page 5-36. Added additional bullet to Section 5.5, “Preconditions for IDL Generation,” on page 5-33 to deal with the fact that the MOF Model does not require model ele-ment names to be legal IDL identifiers! Similar fix made to “Rules for Splitting MOF Model::ModelElement Names into "Words"” on page 5-39. [SC] Implementation: Updated Chapter 3 definitions of MofException -> Exception and MofAttribute -> Attribute, using the "Alternative Name" Tag. Up-dated MODL. Done. [SC] Implementation: Documented that at most one instance of this Tag is allowed per ModelElement: Section 5.6.2, “Tags for providing substitute identi-fiers,” on page 5-36. Done. [SC] End of Annotations:===== Return-Path: From: Tom Digre To: issues Cc: Boca RTF , MOF RTF Subject: mof-rtf issue: IDL mapping/Identifier Naming Date: Mon, 4 May 1998 15:32:30 -0400 MOF, ad/97-08-15 (boca-rtf copied due to BOCA dependency) Issue: Section 7.2.1, ppf 7-2. There is a section on name mangling which describes how a MOF name is mapped to an IDL name. The mapping definition provided has the following problems: * There can be any number of MOF names which map to a single identifier in IDL. A legal configuration of names in a MOF namespace may result in name conflicts when mapped to IDL. Section 7.4, p 7-33 states that the "IDL mapping may not produce valid CORBA IDL if ...preconditions on the input model is not satisfied:... the names within a NameSpace must be unique after application of the Format1 and Format2 name rewriting algorithms." * The name mangling is not based on any standard, but rather "stylistic conventions". * It is unnatural for a user to see different names in his MOF/UML model than in the corresponding IDL. * The IDL for MOF does not even follow the guidelines (see format for constants, ppf A-2, format for exceptions throughout document) * Some forms of identifier are not covered, such as enumeration value, structs, unions, discriminators. * Will need to add arcane mangling rules for object by value and other OMG specifications which extend IDL. I would prefer to see some effort put into MOF NameSpace semantics to provide some level of assurance that a mapping to IDL is possible. The name mangling is yet another obstacle to that objective, and seems to reinforce the statement occuring several places in the document that "a conformant MOF implementation is not required to support automatic IDL generation". I am also not satisfied with the coupling of IDL generation integrity to the MOF model. Section 7.4, p 7-33, (Preconditions for successful IDL mapping) states preconditions for successful IDL mapping. The preconditions, particularly the NameSpace uniqueness conditions, are not expressed as constraints within the MOF model, so there is never any apriori assurance that a MOF model can be mapped to IDL. RECOMMENDATION: Remove section 7.2.1 (Identifier Naming) in its entirety. Return-Path: Date: Thu, 30 Jul 1998 07:07:45 -0700 From: GK Khalsa Organization: Object Radiance, Inc. To: "mof-rtf@omg.org" Subject: Discussion of Issue 1307 Discussion of Issue 1307: IDL Mapping/Identifier Naming This is an issue that will not go away. Developers will always want some alternate representation of IDL. For instance, the generation of the accessor (read) operation from References and MofAttributes -- some_property() from someProperty -- defeats Java IDEs that make use of the standard "design pattern" of JavaBeans -- getSomeProperty(). The solution is to map the MOF Model transformation to an IDL Model. In absence of a mapping, the standard IDL mapping is assumed. Whenever there was a divergence, the Class is mapped to the Interface, the MofAttribute is mapped to the read and write operations, etc. This approach works for JavaBeans BeanInfo (and presumably for the upcoming ComponentInfo). Once a Model has IDL generated, this mapping must become part of the Model (at least for CORBA implementation and access). -- GK Khalsa khalsa@objectrad.com Object Radiance, Inc. v: +1 909 677 2518 Murrieta, CA USA f: +1 909 677 1478 Return-Path: To: GK Khalsa cc: "mof-rtf@omg.org" , crawley@dstc.edu.au Subject: Re: Discussion of Issue 1307 Date: Fri, 31 Jul 1998 14:48:15 +1000 From: Stephen Crawley GK, You wrote: > The solution is to map the MOF Model transformation to an > IDL Model. In absence of a mapping, the standard IDL mapping > is assumed. Whenever there was a divergence, the Class is > mapped to the Interface, the MofAttribute is mapped to the > read and write operations, etc. This approach works for > JavaBeans BeanInfo (and presumably for the upcoming > ComponentInfo). > > Once a Model has IDL generated, this mapping must become > part of the Model (at least for CORBA implementation and > access). I'm having difficulty understanding what you are saying here. This something like what I think you mean ... The MOF spec defines one and only one standard 'transformation' from the MOF Model to IDL text. The result of the transformation could be a MOF-based IDL model instead of IDL text. I think you are also suggesting that there should also be a MOF-based Mapping meta-model that relates elements of a meta-model to elements of an IDL model; i.e. 1 Model::Class relates to 2 IDL::Interface (instance) (class proxy) 1 IDL::Attribute (class ref link in package) 1 IDL::Operation (create operation in proxy) 1 Model::MofAttribute relates to many IDL::Operation depending on multiplicity, is_derived, is_readonly, scope, etc and so on. One would use the Mapping meta-model to express (for example) that the 'getter' operation for a 'foo' attribute was called 'getFoo' rather than 'foo'. By default the mapping would be generated automatically according to and in parallel with the standard MOF Model to IDL transformation. If the user wants a non-standard mapping, he can 'edit' the generated IDL model, and/or the Mapping model using some vendor provided tool. Alternatively, he could use some vendor provided tool that implemented non-standard transformation (e.g. based on Tag extensions to the Model), and generated different IDL and Mapping models. Finally, the vendor might even provide tools for defining new transformations. This sort of thing is the way to go in the long term, but there are a number of problems with addressing them here: 1) There is no standard MOF-based meta-model for CORBA IDL ... yet 2) There is no standard MOF-based meta-model for mappings 3) Mechanisms for defining model to model transformations are too immature to standardize right now. Points 1) and 2) are do-able now, but these are beyond our scope here. They should be a addressed as separate RFP, or maybe an RFC. Point 3) is probably too premature even for an RFP. Maybe an RFI would help stimulate the work that needs to be done. Actually, we are starting to see lots of problems in which this sort of technology would be useful. In summary, in this RTF we should confine ourselves to less grandiose solutions. Or put off addressing the problem at all ... for now. After all, even the simplest solutions are non-trivial extensions to the MOF spec. And that's not what an RTF is constituted to do! -- Steve