Issue 5957: Inconsistent use of label attribute in DeploymentPlan (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: Elements of the DeploymentPlan use the "label" attribute and describe it as a unique identifier, which is inconsistent with the description of the label attribute in the modeling conventions. Proposed resolution: Elements of the DeploymentPlan do not need a "human readable label". They should have "name" and "source" attributes. The Planner can generate unique names for all elements, and use the "source" attribute to provide traceability, by filling it with location data for the source element in the Component Data Model. In an error condition, the exception can indicate the name of the faulty item in the Deployment Plan, a user can then locate this element by name, read the source attribute, and thus trace the error to the original element. In section 3.8, "Execution Data Model", in the Attributes section for the ArtifactDeploymentDescription class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] Identifies the ImplementationArtifact- Description elements that caused this artifact to be part of the deployment. Replace the third paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and Implementation- ArtifactDescription elements, describing a "path" of the artifact's origins in the Component Data Model. The source attribute may have more than one element, since Artifact- DeploymentDescription elements may be shared among instance deployments, if the same implementation artifact is part of multiple component implementations. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the MonolithicDeploymentDescrip- tion class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] Identifies the MonolithicImplementation- Description elements that caused this component to be part of the deployment. Replace the second paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and MonolithicImple- mentationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. The source attribute may have more than one element, since MonolithicDeploymentDescription elements may be shared among instance deployments, if the same component implementation artifact is deployed more than once. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the InstanceDeploymentDescrip- tion class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String Identifies the MonolithicImplementation- Description elements that caused this component to be part of the deployment. Replace the first paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and MonolithicImple- mentationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the PlanConnectionDescription class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] The labels of all AssemblyConnection De- scription elements that were combined into this PlanConnectionDescription. Add to the Semantics section: A Planner may compose a human readable value for the source attribute by combining the label attributes of package imple- mentations, assembly subcomponents and AssemblyConnectionDe- scription elements, describing a "path" of the connection's origins in the Component Data Model. The source attribute may have more than one element, since a connection in the "flatte- ned" plan might be a combination of multiple connection segments on different levels of the assembly hierarchy. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the PlanPropertyMapping class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] The labels of all AssemblyConnection De- scription elements that were combined into this PlanConnectionDescription. Add to the Semantics section: A Planner may compose a human readable value for the source attribute by combining the label attributes of package imple- mentations, assembly subcomponents and AssemblyPropertyMapping elements, describing a "path" of the mapping's origins in the Component Data Model. The source attribute may have more than one element, since a mapping in the "flattened" plan might be a combination of multiple mapping "segments" on different levels of the assembly hierarchy. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In section 3.11, "Exceptions", rename the "label" attribute to "name" in the ResourceNotAvailable, PlanError, StartError and StopError exceptions. For consistency, also make a similar change in the PackageError exception: delete the "label" attribute, and add a "source" attribute: - source: String Identifies a location in the package where the error occured. Change the Semantics section to read: The implementation of the RepositoryManager interface should compose a human readable value for the source attribute from the label attributes of elements in the hierarchy defined by the PackageConfiguration, ComponentPackageDescription, Compo- nentImplementationDescription, SubcomponentInstantiationDe- scription, AssemblyConnectionDescription, AssemblyProperty- Mapping and ImplementationArtifactDescription elements so that a user can locate the problem as precisely as possible. Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: Inconsistent use of label attribute in DeploymentPlan Date: Thu, 19 Jun 2003 10:04:01 -0400 Thread-Topic: Inconsistent use of label attribute in DeploymentPlan Thread-Index: AcM2a6KSIY0Pvf19TsmN0Ib841LHlg== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JE3bkM002616 This is a new issue for the Deployment FTF: Elements of the DeploymentPlan use the "label" attribute and describe it as a unique identifier, which is inconsistent with the description of the label attribute in the modeling conventions. Proposed resolution: Elements of the DeploymentPlan do not need a "human readable label". They should have "name" and "source" attributes. The Planner can generate unique names for all elements, and use the "source" attribute to provide traceability, by filling it with location data for the source element in the Component Data Model. In an error condition, the exception can indicate the name of the faulty item in the Deployment Plan, a user can then locate this element by name, read the source attribute, and thus trace the error to the original element. In section 3.8, "Execution Data Model", in the Attributes section for the ArtifactDeploymentDescription class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] Identifies the ImplementationArtifact- Description elements that caused this artifact to be part of the deployment. Replace the third paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and Implementation- ArtifactDescription elements, describing a "path" of the artifact's origins in the Component Data Model. The source attribute may have more than one element, since Artifact- DeploymentDescription elements may be shared among instance deployments, if the same implementation artifact is part of multiple component implementations. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the MonolithicDeploymentDescrip- tion class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] Identifies the MonolithicImplementation- Description elements that caused this component to be part of the deployment. Replace the second paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and MonolithicImple- mentationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. The source attribute may have more than one element, since MonolithicDeploymentDescription elements may be shared among instance deployments, if the same component implementation artifact is deployed more than once. In case of an error, a user can use this information to track the problem and identify its source. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the InstanceDeploymentDescrip- tion class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the Deploymees: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] The labels of all AssemblyConnection De- scription elements that were combined into Subject: Updated proposed resolution for issue 5957 Date: Wed, 23 Jul 2003 16:12:41 -0400 Thread-Topic: Inconsistent use of label attribute in DeploymentPlan Thread-Index: AcM2bDr1cn44HaJeEdeMjQCgyTbmFwa6R2Vw From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6NK9akM007171 This is an update of the proposed resolution for issue 5957: Elements of the DeploymentPlan use the "label" attribute and describe it as a unique identifier, which is inconsistent with the description of the label attribute in the modeling conventions. In the following proposed resolution, the following sentence has been truncated to avoid overloading of the term "source" (in four occurences): Old: In case of an error, a user can use this information to track the problem and identify its source. Updated: In case of an error, a user can use this information to track the problem. Also, a constraint on the DeploymentPlan is introduced that the names of its elements must be unique within the plan. The full text of the updated proposed resolution follows: Elements of the DeploymentPlan do not need a "human readable label". They should have "name" and "source" attributes. The Planner can generate unique names for all elements, and use the "source" attribute to provide traceability, by filling it with location data for the source element in the Component Data Model. In an error condition, the exception can indicate the name of the faulty item in the Deployment Plan, a user can then locate this element by name, read the source attribute, and thus trace the error to the original element. In section 3.8, "Execution Data Model", in the Constraints section for the DeploymentPlan class, add the text: The top-level elements in a DeploymentPlan all have name attributes. These names must be unique within the plan. context DeploymentPlan inv: let elements = Set {self.artifact, self.implementation, self.instance, self.connection, self.externalProperty} elements.forAll (e1, e2 | e1.name = e2.name implies e1 = e2) In section 3.8, "Execution Data Model", in the Attributes section for the ArtifactDeploymentDescription class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] Identifies the ImplementationArtifact- Description elements that caused this artifact to be part of the deployment. Replace the third paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and Implementation- ArtifactDescription elements, describing a "path" of the artifact's origins in the Component Data Model. The source attribute may have more than one element, since Artifact- DeploymentDescription elements may be shared among instance deployments, if the same implementation artifact is part of multiple component implementations. In case of an error, a user can use this information to track the problem. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the MonolithicDeploymentDescrip- tion class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] Identifies the MonolithicImplementation- Description elements that caused this component to be part of the deployment. Replace the second paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and MonolithicImple- mentationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. The source attribute may have more than one element, since MonolithicDeploymentDescription elements may be shared among instance deployments, if the same component implementation artifact is deployed more than once. In case of an error, a user can use this information to track the problem. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the InstanceDeploymentDescrip- tion class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String Identifies the MonolithicImplementation- Description elements that caused this component to be part of the deployment. Replace the first paragraph of the Semantics section ("A Planner can generate a human readable label ...") with A Planner may compose a human readable value for the source attribute by combining the label attributes of packages, implementations, assembly subcomponents and MonolithicImple- mentationDescription elements, describing a "path" of the component implementation's origins in the Component Data Model. In case of an error, a user can use this information to track the problem. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the PlanConnectionDescription class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] The labels of all AssemblyConnection De- scription elements that were combined into this PlanConnectionDescription. Add to the Semantics section: A Planner may compose a human readable value for the source attribute by combining the label attributes of package imple- mentations, assembly subcomponents and AssemblyConnectionDe- scription elements, describing a "path" of the connection's origins in the Component Data Model. The source attribute may have more than one element, since a connection in the "flatte- ned" plan might be a combination of multiple connection segments on different levels of the assembly hierarchy. In case of an error, a user can use this information to track the problem. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In the Attributes section for the PlanPropertyMapping class, delete the "label" attribute, and add "name" and "source" attributes: - name: String A unique identifier for this element of the DeploymentPlan - source: String [*] The labels of all AssemblyConnection De- scription elements that were combined into this PlanConnectionDescription. Add to the Semantics section: A Planner may compose a human readable value for the source attribute by combining the label attributes of package imple- mentations, assembly subcomponents and AssemblyPropertyMapping elements, describing a "path" of the mapping's origins in the Component Data Model. The source attribute may have more than one element, since a mapping in the "flattened" plan might be a combination of multiple mapping "segments" on different levels of the assembly hierarchy. In case of an error, a user can use this information to track the problem. A Planner must generate a name that is unique among the top- level elements in a DeploymentPlan. In section 3.11, "Exceptions", rename the "label" attribute to "name" in the ResourceNotAvailable, PlanError, StartError and StopError exceptions. For consistency, also make a similar change in the PackageError exception: delete the "label" attribute, and add a "source" attribute: - source: String Identifies a location in the package where the error occured. Change the Semantics section to read: The implementation of the RepositoryManager interface should compose a human readable value for the source attribute from the label attributes of elements in the hierarchy defined by the PackageConfiguration, ComponentPackageDescription, Compo- nentImplementationDescription, SubcomponentInstantiationDe- scription, AssemblyConnectionDescription, AssemblyProperty- Mapping and ImplementationArtifactDescription 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 > Fax: +49 30 3463-8392 > Email: andreas. 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 Date: Sat, 18 Oct 2003 21:54:09 -0400 Thread-Topic: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Thread-Index: AcOU8uaB9jNtCmcaRd+EFxP2so3RqwA7g5PQ From: "Pilhofer, Frank" To: "Kevin Richardson" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9J1nY2U028067 Hi Kevin, thanks for the work you spent on this. Here are some comments. > > 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) > You're right, the "label" attribute still occurs in a few places where it shouldn't. I can find it in 6.4.9.1 (AssemblyConnectionDescription) and 6.8.3.1 (MonolithicDeploymentDescription) and in the diagram for 6.11.1. I cannot find the other occurences you mention. The diagram needs to be updated. for the other two occurences, the offending text should be deleted (by a separate issue, if this resolution is adopted). > 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? Well, in the usual CORBA sense, anything on disk - like an XML file - is persistent, as files persist across server restarts. No persistency in the sense "it needs to be kept around for any amount of time" is implied, but maybe this needs better wording. > 2) The paragraph beginning with "Composition associations in the > model..." confuses me to no end, am I just missing something? This section elaborates the potential spreading of XML data across multiple files - it is possible, but not mandatory, to store information in multiple rather than a single file. When the model uses a composite association, e.g. a Node containing Resources, then these Resources are owned by the Node, and it is inappropriate to share information about the Resource, as the Node is its sole parent. In an XML document, information about the Resource will always be directly embedded within the Node's information, e.g. www.omg.org .... Because of the XMI rules, however, the Resource information may be placed in a different file, and the Node can then use an http: XLink to link to the Resource data. Maybe the text needs some fine-tuning, but I don't think this should deter us from accepting the resolution, which makes a worthwile change overall. Frank 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 260-429-5060 Fax Subject: Updating diagrams Date: Tue, 21 Oct 2003 09:36:02 -0400 Thread-Topic: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Thread-Index: AcOXGQ2fuwBcYLttTq6GKZIjp/d87AAvTfRw From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9LDVC2U018285 > OMG Issue No: 5957: Yes, but diagrams need to be updated too IMHO, this implicitly goes without saying. Although we don't say it anywhere, I consider the text to be normative and the diagrams to be explanatory. According to this logic, inconsistencies in diagrams (with respect to the text) may be treated as editorial. Frank