Issue 5962: References chapter is empty (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: References to specific versions of MOF, UML, XMI, UML Profile to CORBA, URIs etc. should be mentioned. Proposed resolution: Add "normative" references to: - CORBA Components 3.0 - HTTP 1.1 (RFC 2616) - MIME (RFC 2045) - MOF 1.4 - UML 1.5 - UML Profile for CORBA - Uniform Resource Identifiers (RFC 2396) - Uniform Resource Names (RFC 2141) - XML Metadata Interchange 2.0 - Extensible Markup Language - XML Schema - ZIP File Format Add "non-normative" references to: - MOF 2.0 Core Proposal - UML 2.0 Infrastructure submission - UML 2.0 Superstructure submission - UML Profile for QoS submission Use these references throughout the document wherever appropriate. Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: References chapter is empty Date: Thu, 19 Jun 2003 10:59:33 -0400 Thread-Topic: References chapter is empty Thread-Index: AcM2c2TV2RUyZafmQz2DELbAWtFAYA== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JEx5kM003632 This is an issue for the Deployment FTF: References to specific versions of MOF, UML, XMI, UML Profile to CORBA, URIs etc. should be mentioned. Proposed resolution: Add "normative" references to: - CORBA Components 3.0 - HTTP 1.1 (RFC 2616) - MIME (RFC 2045) - MOF 1.4 - UML 1.5 - UML Profile for CORBA - Uniform Resource Identifiers (RFC 2396) - Uniform Resource Names (RFC 2141) - XML Metadata Interchange 2.0 - Extensible Markup Language - XML Schema - ZIP File Format Add "non-normative" references to: - MOF 2.0 Core Proposal - UML 2.0 Infrastructure submission - UML 2.0 Superstructure submission - UML Profile for QoS submission Use these references throughout the document wherever appropriate. 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 Be= > > (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 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: Mon, 20 Oct 2003 18:40:39 +0200 From: Andreas Hoffmann Organization: Fraunhofer FOKUS 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: de, en, en-us, en-gb To: dwfitkin@rockwellcollins.com, fpilhofe@mc.com CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Hi David and Frank, here is my answer on your discussion - a bit late since I was out of my office for two weeks. dwfitkin@rockwellcollins.com wrote: Frank, Your "editorial amendments" aren't really in the editorial class. I would suggest you submit them as issues once the voting is completed. David I agree with David. Issue resolutions should not be changed while the voting is in progress. So only the first issue #5962 regarding the wrong title should be corrected since the vote on an issue is mainly based on the description given in the summary section, and the resolution of this issue to vote on is not affected. For all other proposed changes new issues should be raised after the voting deadline has passed. Regards Andreas "Pilhofer, Frank" 10/03/2003 09:07 AM To: "Andreas Hoffmann" , "Deployment FTF" cc: Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Mercury votes YES on all issues. I have the following friendly editorial amendments: - In the voting document, the title of issue 5962 is wrong, should be "References chapter is empty" - Issue 5962 includes a reference to MIME (RFC 2045). However, that is superfluous with the acceptance of issue 6024, which removes the explicit reference to Base64 (by using the xsd:base64Binary type instead). So that reference should be removed from the resolution for issue 5962. - In the resolution for issue 6024, the "type" attribute of the ValueType class should be renamed to "typeId". - Also in the resolution for 6024, the "members" attribute of the EnumType class should be renamed to "member". -- 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 ====================================================================