Issue 5964: No Traceability if optional labels are blank (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The Execution Data Model explains that the Planner may construct label attributes from the Component Data Model's label attributes. This is problematic, and does not provide traceability if the original label attributes are empty. An alternative is to name each subelement. This is easy e.g. in the ComponentAssemblyDes- cription, by changing the label attribute to name. For the implementations in a package, or for artifacts in a monolithic implementation, a qualified association could be used, were they available in MOF (they are not); new classes would have to be introduced, such as a NamedComponentImplementationDescription class that is contained by the ComponentPackageDescription, has a name attribute and a reference to the "real" ComponentImple- mentationDescription. Proposed resolution: In the elements of a ComponentAssemblyDescription (Subcomponent- instantiationDescription, AssemblyConnectionDescription, Assembly- PropertyMapping), change the "label" attribute to a "name" attri- bute, and clarify that the name must be unique among these ele- ments. Introduce a new class NamedComponentImplementationDescription with a 1..1 association to ComponentImplementationDescription. Edit ComponentPackageDescription by making its 1..* "implements" relationship point to the new class. Introduce a new class NamedImplementationArtifactDescription with a 1..1 association to ImplementationArtifactDescription. Edit MonolithicImplementationDescription by making its 1..* "primaryArtifact" relationship point to the new class. Edit ImplementationArtifactDescription by making its 0..* "dependsOn" relationship point to the new class. Throughout the ExecutionDataModel, clarify that these names are used (instead of labels) to generate a human readable path that identifies the source element. Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: No Traceability if optional labels are blank Date: Thu, 19 Jun 2003 11:06:14 -0400 Thread-Topic: No Traceability if optional labels are blank Thread-Index: AcM2dFN7AMhEoUxCReWR+HadzwVm2Q== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JF5jkM003760 This is an issue for the Deployment FTF: The Execution Data Model explains that the Planner may construct label attributes from the Component Data Model's label attributes. This is problematic, and does not provide traceability if the original label attributes are empty. An alternative is to name each subelement. This is easy e.g. in the ComponentAssemblyDes- cription, by changing the label attribute to name. For the implementations in a package, or for artifacts in a monolithic implementation, a qualified association could be used, were they available in MOF (they are not); new classes would have to be introduced, such as a NamedComponentImplementationDescription class that is contained by the ComponentPackageDescription, has a name attribute and a reference to the "real" ComponentImple- mentationDescription. Proposed resolution: In the elements of a ComponentAssemblyDescription (Subcomponent- instantiationDescription, AssemblyConnectionDescription, Assembly- PropertyMapping), change the "label" attribute to a "name" attri- bute, and clarify that the name must be unique among these ele- ments. Introduce a new class NamedComponentImplementationDescription with a 1..1 association to ComponentImplementationDescription. Edit ComponentPackageDescription by making its 1..* "implements" relationship point to the new class. Introduce a new class NamedImplementationArtifactDescription with a 1..1 association to ImplementationArtifactDescription. Edit MonolithicImplementationDescription by making its 1..* "primaryArtifact" relationship point to the new class. Edit ImplementationArtifactDescription by making its 0..* "dependsOn" relationship point to the new class. Throughout the ExecutionDataModel, clarify that these names are used (instead of labels) to generate a human readable path that identifies the source element. Subject: Proposed resolution for issue 5964 Date: Wed, 23 Jul 2003 17:05:11 -0400 Thread-Topic: No Traceability if optional labels are blank Thread-Index: AcM2dQE7cn5C4KJeEdeMjQCgyTbmFwa4hS2Q From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6NL2BkM007780 The current proposed resolution for issue 5964 is more explanatory guidelines, not suitable for a vote. Now that everybody seems to agree that action is necessary, here is a set of document edits to resolve the issue. Note that this resolution is based on the resolution for issue 5957. The original text of the issue: > > The Execution Data Model explains that the Planner may construct > label attributes from the Component Data Model's label attributes. > This is problematic, and does not provide traceability if the > original label attributes are empty. An alternative is to name > each subelement. This is easy e.g. in the ComponentAssemblyDes- > cription, by changing the label attribute to name. For the > implementations in a package, or for artifacts in a monolithic > implementation, a qualified association could be used, were they > available in MOF (they are not); new classes would have to be > introduced, such as a NamedComponentImplementationDescription > class that is contained by the ComponentPackageDescription, has > a name attribute and a reference to the "real" ComponentImple- > mentationDescription. > Proposed resolution: In chapter 3.4, "Component Data Model," make the following changes. Add a new class PackagedComponentImplementation as follows: PackagedComponentImplementation Description PackagedComponentImplementation is used by the ComponentPackage- Description to assign names to alternative ComponentImplementation- Description elements within that package. This information can be used to identify elements within the Component Data Model using a "path name" from the top level package downwards. Attributes name: String The name assigned to this implementation. Associations referencedImplementation: ComponentImplementationDescription [1] The implementation that is referenced by this package. Constraints No constraints. Semantics No semantics. In the Associations section for class ComponentPackageDescription, delete the association "implementation" to ComponentImplementation- Description, and add a new "implementation" association as follows: implementation: PackagedComponentImplementation [1..*] The alternative implementations for this component. In the Constraints section for class ComponentPackageDescription, edit "self.implementation" and change to "self.implementation.refe- rencedImplementation". Also in the Constraints section for class ComponentPackageDescription, add a new constraint: The names assigned to implementations must be unique within this package. context ComponentPackageDescription inv: implementation->forAll (i1,i2 | i1.name=i2.name implies i1=i2) In the Constraints section for class ComponentAssemblyDescription, add a new constraint The elelements within this ComponentAssemblyDescription (SubcomponentInstantiationDescription, AssemblyConnection- Description and AssemblyPropertyMapping) must have unique names within this context. context ComponentAssemblyDescription: let elements = Set {self.instance, self.connection, self.externalProperty} elements->forAll (e1, e2 | e1.name = e2.name implies e1 = e2) In the Attributes section for class SubcomponentInstantiation- Description, delete attribute "label" and add attribute "name" as follows: name: String Identifies this subcomponent instance within the assembly. In the Attributes section for class AssemblyConnectionDescription, delete attribute "label" and add attribute "name" as follows: name: String Identifies this connection within the assembly. In the Attributes section for class AssemblyPropertyMapping, delete attribute "label" and add attribute "name" as follows: name: String Identifies this property mapping within the assembly. Add a new class NamedImplementationArtifact as follows: NamedImplementationArtifact Description NamedImplementationArtifact is used by MonolithicImplementation- Description and ImplementationArtifactDescription to assign names to primary artifacts and dependee artifacts, respectively. This information can be used to identify implementation artifacts within the Component Data Model using a "path name" from the top level package downwards. Attributes name: String The name assigned to this implementation artifact. Associations referencedArtifact: ImplementationArtifactDescription [1] The named implementation artifact. Constraints No constraints. Semantics No semantics. In the Associations section for class MonolithicImplementationDescrip- tion, delete the association "primaryArtifact" to ImplementationArti- factDescription, and add a new "primaryArtifact" association as follows: primaryArtifact: NamedImplementationArtifact [1..*] The primary implementation artifacts. In the Constraints section for class MonolithicImplementationDescrip- tion, remove the "No constraints" comment and add the constraint The names assigned to primary artifacts must be unique within this context. context MonolithicImplementationDescription: primaryArtifact->forAll (a1,a2 | a1.name=a2.name implies a1=a2) In the Associations section for class ImplementationArtifactDescrip- tion, delete the association "dependsOn" to ImplementationArtifact- Description, and add a new "dependsOn" association as follows: dependsOn: NamedImplementationArtifact [*] References other ImplementationArtifactDescription elements for implementation artifacts that this implementation artifact depends on, assigning names to each. In the Constraints section for class ImplementationArtifactDescription, add the constraint The names assigned to dependee artifacts must be unique within this context. context ImplementationArtifactDescription: dependsOn->forAll (a1, a2 | a1.name = a2.name implies a1 = a2) In chapter 3.8, "Execution Data Model," make the following changes: In the Semantics section for class ArtifactDeploymentDescription, change the first sentence of the third paragraph from A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assem- bly subcomponents and ImplementationArtifactDescription elements, describing a "path" of the artifact's origins in the Component Data Model. to read A Planner may compose a human readable value for the source attribute by combining the name attributes from PackageConfiguration, Packaged- ComponentImplementation, SubcomponentInstantiationDescription and NamedImplementationArtifact elements, describing a "path" of the artifact's origins in the Component Data Model. In the Semantics section for class MonolithicDeploymentDescription, change the first sentence of the second paragraph from A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assem- bly subcomponents and MonolithicImplementationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. to read A Planner may compose a human readable value for the source attribute by combining the name attributes from PackageConfiguration, Packaged- ComponentImplementation and SubcomponentInstantiationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. In the Semantics section for class InstanceDeploymentDescription, change the first sentence of the first paragraph from A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assem- bly subcomponents and MonolithicImplementationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. to read A Planner may compose a human readable value for the source attribute by combining the name attributes from PackageConfiguration, Packaged- ComponentImplementation and SubcomponentInstantiationDescription elements, describing a "path" of the instance's origins in the Component Data Model. In the Semantics section for class PlanConnectionDescription, change the first sentence of the second paragraph from A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assem- bly subcomponents and AssemblyConnectionDescription elements, describing a "path" of the connection's origins in the Component Data Model. to read A Planner may compose a human readable value for the source attribute by combining the name attributes PackageConfiguration, Packaged- ComponentImplementation, SubcomponentInstantiationDescription and AssemblyConnectionDescription elements, describing a "path" of the connection's origins in the Component Data Model. In the Constraints section for class PlanPropertyMapping, insert a new section "Semantics" after the first paragraph, then edit the first sentence of the now-first paragraph of the Semantics section from A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assem- bly subcomponents and AssemblyPropertyMapping elements, describing a "path" of the mapping's origins in the Component Data Model. to read A Planner may compose a human readable value for the source attribute by combining the name attributes PackageConfiguration, Packaged- ComponentImplementation, SubcomponentInstantiationDescription and AssemblyPropertyMapping elements, describing a "path" of the connection's origins in the Component Data Model. In chapter 3.11, "Exceptions," make the following changes: In the Semantics section for class PackageError, edit the first sentence of the first paragraph from The implementation of the RepositoryManager interface should compose a human readable value for the source attribute from the label attri- butes of elements in the hierarchy defined by the PackageConfiguration, ComponentPackageDescription, ComponentImplementationDescription, Sub- componentInstantiationDescription, AssemblyConnectionDescription, AssemblyPropertyMapping and ImplementationArtifactDescription elements so that a user can locate the problem as precisely as possible. to read The RepositoryManager implementation should compose a human readable value for the source attribute from the name attributes of elements in the hierarchy defined by the PackagedComponentImplementation, SubcomponentInstantiationDescription, AssemblyConnectionDescription, AssemblyPropertyMapping and NamedImplementationArtifact elements so that a user can locate the problem as precisely as possible. Date: Fri, 17 Oct 2003 17:07:21 -0400 From: Kevin Richardson Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en To: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT One note, please consider indicate the exact subsections where the modifications are to take place (this makes it much easier for me to find the text in the document) OMG Issue No: 5953: Yes OMG Issue No: 5954: Yes OMG Issue No: 5955: No - I'd suggest that the semantics of ComponentPackageReference be made more generic and that the particulars of each association to it be restructured to specify the semantics of how a componentpackagerefernce should be used in that case OMG Issue No: 5956: Yes OMG Issue No: 5957: No - in InstanceDeploymentDescrition, PlanConnectionDescription, PlanPropertyMapping, PackageError there are still references to the label attribute. The resolution should also contain explicit instructions to update the figures. (if these are incorporated - Yes) OMG Issue No: 5958: Yes OMG Issue No: 5959: No - I've got a couple of discussion items before I say yes, 1) In the GenericTransformationRules it states the "an XML schema for persistent storage of metadata" - is it the case that the metadata has to be persistently maintained? 2) The paragraph beginning with "Composition associations in the model..." confuses me to no end, am I just missing something? OMG Issue No: 5960: Yes OMG Issue No: 5961: No - The semantics of CreatePackage need to better explain what distinguishes this operation from InstallPackage - you can probably use some of the text from the summary. It should also explicitly state that it creates the new PackageConfiguration. OMG Issue No: 5962: Yes (the title needs to be changed in the report) OMG Issue No: 5963: No - I couldn't figure out what the changes were supposed to be. OMG Issue No: 5964: No - Make sure instructions say to update the diagrams (for the label to name change) and the diagram in 6.4.1 (for the new class if necessary) In the dependsOn association remove the text ", assigning names to each" . In the referencedArtifact association its definition should be more descriptive, to explain that it represents to pointer to another artifact. Section 6.4.9.1 still has references to the "label" attribute. OMG Issue No: 5983: Yes OMG Issue No: 5984: Yes OMG Issue No: 5985: No - This change also needs to incorporate the T2 to T3 transformation in 9.1 OMG Issue No: 5986: Yes OMG Issue No: 5993: Yes OMG Issue No: 6024: Yes OMG Issue No: 6037: Yes OMG Issue No: 6038: Yes OMG Issue No: 6041: Yes OMG Issue No: 6042: No - This may be a hostage for another item which will result in an issue being raised, but section 8.2.4.1 describes capabilities not capacities OMG Issue No: 6044: Yes OMG Issue No: 6046: Yes OMG Issue No: 6048: Yes OMG Issue No: 6051: Yes OMG Issue No: 6052: Yes Kevin > > Andreas Hoffmann > > unhofer.de> cc: > Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT > 10/02/2003 10:07 AM > > > > Hi FTF members, > > this is the first voting for the OMG Deployment FTF. For details on the > issue resolutions please refer to the attached document listing all the > issue resolutions of this voting. Compared to Tuesday's draft version I > have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" > to "Duplicate or merged". Anyway, this classification has no impact on the > voting. > > In order to give all FTF members enough time to study the issue resolutions > and their impacts on the specification the voting deadline is Monday 20th > October, 2003, 20:00 GMT. > > ------------------- snip -------------------- > > ** Deployment FTF Voting Poll 1 ** > ** Voting Deadline October 20, 2003, 20:00 GMT ** > > Company: > > Voter: > > Regards > Andreas > > ==================================================================== > Andreas Hoffmann > Fraunhofer FOKUS - Research Institute for Open Communication Systems > Kaiserin-Augusta-Allee 31 > D - 10589 Berlin > > Phone: +49 30 3463-7392 > Fa Date: Sat, 18 Oct 2003 09:04:12 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: Kevin Richardson CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Kevin, Similar to the email to Dave, since Frank isn't around, I'll try to clarify some of the issues that you didn't want to accept. In general, to make progress, when comments come up at the ballot that were not raised earlier during the email and telecon discussions, it might be more efficient to raise them as new issues - especially in the case where they are making minor improvements to the larger proposed resolutions. Your call of course. Kevin Richardson wrote: One note, please consider indicate the exact subsections where the modifications are to take place (this makes it much easier for me to find the text in the document) OMG Issue No: 5953: Yes OMG Issue No: 5954: Yes OMG Issue No: 5955: No - I'd suggest that the semantics of ComponentPackageReference be made more generic and that the particulars of each association to it be restructured to specify the semantics of how a componentpackagerefernce should be used in that case The core difference was between a reference to an implementation vs. a reference to an interface, which were considered to be distinct enough to warrant different classes. OMG Issue No: 5956: Yes OMG Issue No: 5957: No - in InstanceDeploymentDescrition, PlanConnectionDescription, PlanPropertyMapping, PackageError there are still references to the label attribute. The resolution should also contain explicit instructions to update the figures. (if these are incorporated - Yes) OMG Issue No: 5958: Yes OMG Issue No: 5959: No - I've got a couple of discussion items before I say yes, 1) In the GenericTransformationRules it states the "an XML schema for persistent storage of metadata" - is it the case that the metadata has to be persistently maintained? The persistence is certainly not normative. Perhaps such a clarification should be a separate issue? The core issue of using the standard XMI->XML Schema mapping was mandated by the Architecture Board. 2) The paragraph beginning with "Composition associations in the model..." confuses me to no end, am I just missing something? Me too:-) Perhaps a separate issue to clarify these few sentences? OMG Issue No: 5960: Yes OMG Issue No: 5961: No - The semantics of CreatePackage need to better explain what distinguishes this operation from InstallPackage - you can probably use some of the text from the summary. It should also explicitly state that it creates the new PackageConfiguration. This new operation description was carefully written to mirror the wording for the installPackage operation, which, now that I look at it, could benefit from your comments in the same way. Perhaps a new issue that applied your comments to both? OMG Issue No: 5962: Yes (the title needs to be changed in the report) OMG Issue No: 5963: No - I couldn't figure out what the changes were supposed to be. The changes were all to change "String" to "String[0..1]" for the attributes already specified in the text as "optional". OMG Issue No: 5964: No - Make sure instructions say to update the diagrams (for the label to name change) and the diagram in 6.4.1 (for the new class if necessary) In the dependsOn association remove the text ", assigning names to each" . In the referencedArtifact association its definition should be more descriptive, to explain that it represents to pointer to another artifact. Section 6.4.9.1 still has references to the "label" attribute. These good refinements should be submitted as a new issue if this passes... OMG Issue No: 5983: Yes OMG Issue No: 5984: Yes OMG Issue No: 5985: No - This change also needs to incorporate the T2 to T3 transformation in 9.1 OMG Issue No: 5986: Yes OMG Issue No: 5993: Yes OMG Issue No: 6024: Yes OMG Issue No: 6037: Yes OMG Issue No: 6038: Yes OMG Issue No: 6041: Yes OMG Issue No: 6042: No - This may be a hostage for another item which will result in an issue being raised, but section 8.2.4.1 describes capabilities not capacities 6042 was a spelling error. Do you mean a different issue? OMG Issue No: 6044: Yes OMG Issue No: 6046: Yes OMG Issue No: 6048: Yes OMG Issue No: 6051: Yes OMG Issue No: 6052: Yes Kevin Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== (See attached file: omg-deployment-ftf-01_10_03.zip) ------------------------------------------------------------------------ Name: omg-deployment-ftf-01_10_03.zip omg-deployment-ftf-01_10_03.zip Type: application/zip Encoding: base64 Download Status: Not downloaded with message Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT To: deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 20 Oct 2003 09:45:46 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 10/20/2003 09:44:34 AM OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not clear why another class is needed. Changing the meaning of depends on. It seems like there is different dependencies types, loading, execution, uses. This needs further thought with use cases and use case realizations to show justification. OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes, but diagrams need to be updated too OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes., chapter misspelled in 1st change OMG Issue No: 5960: Yes. OMG Issue No: 5961: no, what is the relationships between this and the install operation. What is the outcome of a createpackage? OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - It appears the changes are being made to agree with the corresponding text. I don't think the text is correct. These attributes should not be optional. OMG Issue No: 5964: NO, Which issue change has precedence 5957? No mention of updating corresponding diagrams. Without updated diagrams with text changes it is unclear why all these changes are necessary and how all these changes fit together. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: Yes if this valid for XML and transformation rules. solution for this issue. OMG Issue No: 6024: Yes, provided the XML is valid syntax. OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 From: "Francis Bordeleau" To: "Andreas Hoffmann" , "Deployment FTF" Subject: RE: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Date: Mon, 20 Oct 2003 20:52:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi All, No, I am not dead! I apologize for having been out of the loop since the Paris meeting, but I have completely swamped with different things (different project funding propositions, software radio submission, graduate student projects, ...) and it seems that I had a meeting every morning when there was a teleconf, and did not have any meetings the other Wednesdays. Anyway, here is my vote. I should be back on the active mode from now on. I am sorry for sending this email 6 hours after the official end of the poll, but I am at the UML conference this week and there are no internet connections in the location where we are today for the workshops (and I was expecting to be able to send it when coming in this morning). So I had to wait until I come back to the hotel to send the email. I left a voice message to Frank at Mercury to let him know. Hopefully, my vote can still be considered. Thanks, Francis OMG Issue No: 5953: YES OMG Issue No: 5954: YES OMG Issue No: 5955: ABSTAIN. I do not see what problem the new solution solves. The issue is not very well described. So in summary, I abstain instead of voting "NO" because I am guilty of not having participated to the discussion. OMG Issue No: 5956: YES OMG Issue No: 5957: YES OMG Issue No: 5958: YES OMG Issue No: 5959: YES OMG Issue No: 5960: YES. However, we should explicitly mention that the current specification does not address the implementation selection issue. OMG Issue No: 5961: NO. I think that the solution might be right, but the argument is too weak. Not convincing at all. E.g. " It might be useful to have ...", This method would do less than" (please explain). OMG Issue No: 5962: YES OMG Issue No: 5963: YES OMG Issue No: 5964: NO. I do not see how changing "label" for "name" solves the problem. OMG Issue No: 5983: YES OMG Issue No: 5984: YES OMG Issue No: 5985: YES OMG Issue No: 5986: YES OMG Issue No: 5993: YES OMG Issue No: 6024: ABSTAIN. I am not sure of the implication of this change. Any impact? OMG Issue No: 6037: YES OMG Issue No: 6038: YES OMG Issue No: 6041: YES OMG Issue No: 6042: YES OMG Issue No: 6044: YES OMG Issue No: 6046: YES OMG Issue No: 6048: YES OMG Issue No: 6051: YES OMG Issue No: 6052: YES ------------------- snip -------------------- Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== 260-429-5060 Fax