Issue 5963: Use optional attributes for optional values (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: Some attributes (like UUIDs and labels) are described as optional. In the model, optional attributes (multiplicity 0..1) should be used for them; this has the advantage that no empty elements are needed in XML documents; optional attributes could still be mapped to empty (but non-optional, i.e. non-sequence) strings in the PSM for CCM for IDL. Proposed resolution: Make all occurences of "label" and "UUID" attributes optional by changing "label: String" to "label: String [0..1]", likewise for UUID. The default value is set to "" (the empty string). In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", add a paragraph that reads For all attributes of type String with multiplicity 0..1, update the multiplicity to 1..1. If the value is missing in an XML re- presentation of the model, the empty string is used as the default value. Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: Use optional attributes for optional values Date: Thu, 19 Jun 2003 11:04:09 -0400 Thread-Topic: Use optional attributes for optional values Thread-Index: AcM2dAlxOcI1+QEZR8CZBZ7miCN67w== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JF3kkM003721 This is a new issue for the Deployment FTF: Some attributes (like UUIDs and labels) are described as optional. In the model, optional attributes (multiplicity 0..1) should be used for them; this has the advantage that no empty elements are needed in XML documents; optional attributes could still be mapped to empty (but non-optional, i.e. non-sequence) strings in the PSM for CCM for IDL. Proposed resolution: Make all occurences of "label" and "UUID" attributes optional by changing "label: String" to "label: String [0..1]", likewise for UUID. The default value is set to "" (the empty string). In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", add a paragraph that reads For all attributes of type String with multiplicity 0..1, update the multiplicity to 1..1. If the value is missing in an XML re- presentation of the model, the empty string is used as the default value. Subject: Updated proposed resolution for issue 5963 Date: Wed, 20 Aug 2003 10:34:59 -0400 Thread-Topic: Updated proposed resolution for issue 5963 Thread-Index: AcNnKDu7nqJmXTYER7yBKDopAbNobA== From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h7KEZ6e4030637 In the last telecon, I was tasked to work out a concrete proposed resolution for issue 5963 ("use optional attributes for optional values"). Original issue: > > Use optional attributes for optional values > > Some attributes (like UUIDs and labels) are described as > optional. In the model, optional attributes (multiplicity 0..1) > should be used for them; this has the advantage that no empty > elements are needed in XML documents; optional attributes could > still be mapped to empty (but non-optional, i.e. non-sequence) > strings in the PSM for CCM for IDL. > Updated proposed resolution: In section 6.4.2, "PackageConfiguration," update the "label" attribute to have 0..1 multiplicity. In section 6.4.3, "ComponentPackageDescription," update both the "label" and the "UUID" attribute to have 0..1 multiplicity. In section 6.4.4, "ComponentImplementationDescription," update both the "label" and the "UUID" attribute to have 0..1 multiplicity. In section 6.4.15, "ImplementationArtifactDescription," update both the "label" and the "UUID" attribute to have 0..1 multiplicity. In section 6.4.17, "ComponentInterfaceDescription," update both the "label" and the "UUID" attribute to have 0..1 multiplicity. In section 6.6.1, "Domain," update both the "label" and the "UUID" attribute to have 0..1 multiplicity. In section 6.6.2, "Node," update the "label" attribute to have 0..1 multiplicity. In section 6.6.3, "Interconnect," update the "label" attribute to have 0..1 multiplicity. In section 6.6.4, "Bridge," update the "label" attribute to have 0..1 multiplicity. In section 6.8.1, "DeploymentPlan," update the "label" attribute to have 0..1 multiplicity. In section 9.3.1, "ComponentInterfaceDescription," update the "idlFile" attribute to have 0..1 multiplicity. In section 9.4, "PIM for CCM to PSM for CCM for IDL Transformation", add a paragraph that reads For all attributes of type String with multiplicity 0..1, update the multiplicity to 1..1. If the value is missing in an XML representation of the model, the empty string is used as default value. From: 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.10 March 22, 2002 Date: Fri, 17 Oct 2003 09:54:41 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 5.0.10 |March 22, 2002) at 10/17/2003 09:54:43 AM Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not sufficient rationale/justification for adding this additonal complexity. No example of problem being solved by adding this new class. 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. OMG Issue No: 5961: Yes. OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - UUID's, Labels, Attributes should not be optional. The Attributes should clearly be required if needed. This solution causes confusion and presents difficulties for tools and applications to anticipate appropriate actions. OMG Issue No: 5964: Yes. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: No. Voting No on Issue 6024 requires a different solution for this issue. OMG Issue No: 6024: No. Solution allows/causes XML parsing errors. Need to re-think this solution so that validating parsers work with the XML. 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 -------------------- 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) omg-deployment-ftf-01_10_031.zip 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.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 Date: Fri, 17 Oct 2003 17:38:29 -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: dahaverk@rockwellcollins.com CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Dave, I'll just try to provide a bit more explanation for the issues you didn't find acceptable (since Frank is out today). It is unfortunate that some of these issues were not raised during our discussions - or in email dialog. dahaverk@rockwellcollins.com wrote: Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not sufficient rationale/justification for adding this additonal complexity. No example of problem being solved by adding this new class. This was an issue where the class in question was being used in two places, but it turned out that it was not appropriate to re-use - thus rather than using the ComponentPackageReference class in two places, the case of using it as an implementation dependency was incorrect. It previously indicated such dependencies as pointers to implementations (ComponentPackageReference). The change specifies the dependency in a way that is simpler and lighter: that an application of a certain type had to be running, but not necessarily one that the implementer knew a package reference (implementation pointer) for. So the "complexity" of the extra class that has a single string attribute allows the dependency to be simpler, and more flexible - indicate an interface, not an implementation 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. OMG Issue No: 5961: Yes. OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - UUID's, Labels, Attributes should not be optional. The Attributes should clearly be required if needed. This solution causes confusion and presents difficulties for tools and applications to anticipate appropriate actions. This issue as written simply says that attributes that are already optional in the spec should be expressed in a more consistent and better way. It is not making any attributes optional. If you think certain attributes in the spec should or should not be optional, that is a separate issue. UUIDs and labels were just used as examples. OMG Issue No: 5964: Yes. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: No. Voting No on Issue 6024 requires a different solution for this issue. Indeed this could have been specified in a standalone way since the issue 6024 change simply solved this by replacing a MIME reference to base64 encoding with the xsd:base64Binary instead -- which is already built in to XML schemas - obviating the MIME reference. OMG Issue No: 6024: No. Solution allows/causes XML parsing errors. Need to re-think this solution so that validating parsers work with the XML. Per your email with Frank, we'll have to figure out whether this is a problem with the schema or a problem with your tools. No specific error in the schema was identified. I'll try to look at this further tomorrow (Saturday). The tool you use is evidently available for a free trial! Jim 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 -------------------- 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) 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 Date: Sat, 18 Oct 2003 13:06:49 -0400 From: "Manfred R. Koethe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Andreas Hoffmann CC: Deployment FTF Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Hallo Andreas, Here are my votes. Gruss, Manfred ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: 88solutions Corp. Voter: Manfred Koethe Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: YES OMG Issue No: 5954: YES OMG Issue No: 5955: YES 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 OMG Issue No: 5961: YES OMG Issue No: 5962: YES OMG Issue No: 5963: YES WITH COMMENT - The discussions we had on the optionality of UUIDs could never really convince me. However I don't want to spoil the process at this time and may consider to re-issue this after more thinking. OMG Issue No: 5964: YES 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: YES 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 -------------------- -- ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 916 5886 Newton, MA 02465-1553 FAX: +1 (617) 916 5887 U.S.A. _____________________________"We make your business flow"_ 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