Issue 7147: lwCCM issues - proxy homes (lwccm-ftf) Source: THALES (Mr. Olivier Hachet, olivier.hachet(at)thalesgroup.com) Nature: Uncategorized Issue Severity: Summary: This issue concerns the table 4.7 "exluding support for proxy homes", row 1; in section 3.2.5, the last paragraph should be removed. Proposed resolution: Row 1 in the table 4.7, in the "Document Impact", add: Section 3.2.5 last paragraph:remove Resolution: Revised Text: Actions taken: March 10, 2004: received issue Discussion: End of Annotations:===== m: olivier.hachet2@fr.thalesgroup.com To: issues@omg.org Cc: lwccm-ftf@omg.org Subject: lwCCM issues - proxy homes Date: Wed, 10 Mar 2004 16:40:29 +0100 X-Message-Flag: Assurer un suivi X-Mailer: Internet Mail Service (5.5.2653.19) This issue concerns the table 4.7 "exluding support for proxy homes", row 1; in section 3.2.5, the last paragraph should be removed. Proposed resolution: Row 1 in the table 4.7, in the "Document Impact", add: Section 3.2.5 last paragraph:remove Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , Cc: Subject: RE: Draft of ballot 10: speak up now or forever keep your peace Date: Wed, 17 Mar 2004 12:58:10 -0800 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQLhS3KWnjcSpVQS8OTcxr0zLY1zwAqpTSg > Here is your chance to review what is currently proposed to be on ballot > 10. There are 59 resolutions in all (good job folks!). > > Note that the resolution to issue 7159 contains the entire new Classes > chapter, reorganized to conform to other chapter numbers. The entire PDF > file is embedded in the resolution section (tell me if you have problems > reading it). Note that, to separate the chapter reorganization from the > resolution to the package merge and compliance points issues, a new issue > was created for this purpose. This was done to minimize the amount of > duplicate editing that would need to be done and nicely stages the > solution to the package merge problem (if we adopt the proposed > resolution, of course). Note also that this chapter has the hyperlinks to > the parent classes (called "Generalizations"). I plan to add this to the > rest of the document, but that is to be addressed as a separate issue > (there is an issue just for that in the database). > > Please do review these issue resolutions: as I said before, this is the > time to complain about anything that you find objectionable, not after the > vote commences. (I realize that this is not always feasible, but we should > (shall?) do our best.) I object to including issues 7159 and 6347 and their proposed resolutions on this ballot. Re Issue 6347: Issue 6347 asks for a clarification regarding whether "profiles [work] for fixed repositories in UML 2." The approximately 6 pages of recommended changes never clearly answer this question, and compound the confusion regarding metalayers and other meta terminology using inconsistent and imprecise language. For example, the first paragraph proposed to be added states that "when we mention 'Class', in most cases we are dealing with the meta-metaclass 'Class'", even though in the rest of the Superstructure spec this typically refers to a metaclass. A later proposed paragraph discusses an "instance 'S' of Stereotype is a kind of (meta) class. Relating it to a metaclass 'C' ..." So what's the difference here between a stereotype, a metaclass, a "kind of metaclass" and a "kind of (meta) class"? (BTW, I would provide specific references to the paragraphs cited above, but the proposal itself lacks them. All proposals, especially lengthy ones such as thes,e should include specific references (page, section, paragraph) to the areas where we are proposing changes.) At the very least the response to issue 6347 should include a clear, concise response to the specific questions being asked. It also should provide clear, concise definitions for the relevant meta terms (stereotype vs. metaclass vs. meta-metaclass) and use them consistently here and in other parts of the UML 2 specifications. Re Issue 7147: "The Classes chapter is organized differently from all other chapters in the document -- it should be made consistent with the organization of all the other chapters." This Classes chapter was organized differently *intentionally* by the UML 2 submitters, in order to facilitate readability and share common content with the Infrastructure specification. As with most issues of this sort, there are advantages and disadvantages with both approaches. In general, I oppose any large scale changes of this sort in an FTF where the value is highly questionable. They introduce the likelihood of introducing new errors, require a long time for review, and violate one of the FTF/RTF's basic principles of operation: we should specify all proposed changes in such a manner that a non-UML expert (e.g., Linda Heaton) can make the changes. This is clearly a large-scale violation of that principle which establishes a bad precedent for future work. -- Cris