Issue 6382: Troublesome paragraph issue (deployment-ftf) Source: Mercury Computer Systems (Mr. James E. Kulp, nobody) Nature: Uncategorized Issue Severity: Summary: While the problematic paragraph (para 3 in 9.5.8) in the solution to issue 5959 raised by Kevin could possibly be clarified by the proposed text below, the first 4 paragraphs of section 9.5.8 are not normative anyway, but simply elaborate certain flexibilities of the standard XMI MOF-to-XML-schema mapping. Thus while replacing the paragraph might help readers understand it, we might want to consider deleting all these paragraphs since there is no normative content. Any opinions about whether to use this (better?) paragraph or nuke all four of them? Resolution: Revised Text: Actions taken: October 21, 2003: received issue Discussion: End of Annotations:===== mscape-Track-Mars-A: [192.233.20.56] X-Dreamscape-Track-Mars-B: Tue, 21 Oct 2003 18:31:28 -0400 (EDT) Date: Tue, 21 Oct 2003 18:31:23 -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: deployment-ftf@omg.org Subject: Troublesome paragraph issue from Kevin While the problematic paragraph (para 3 in 9.5.8) in the solution to issue 5959 raised by Kevin could possibly be clarified by the proposed text below, the first 4 paragraphs of section 9.5.8 are not normative anyway, but simply elaborate certain flexibilities of the standard XMI MOF-to-XML-schema mapping. Thus while replacing the paragraph might help readers understand it, we might want to consider deleting all these paragraphs since there is no normative content. Any opinions about whether to use this (better?) paragraph or nuke all four of them? Composition associations in UML express that the class at the composite end (the containing class) owns and contains the class at the part end (the contained class). It is typical, in XML documents, for instances of contained classes to be embedded within the instance of the containing class. However, it is also possible to store contained instances by themselves in a separate file by using a proxy (using "href" or "xlink:href") to reference the contained instance in a separate file. Since the multiplicity on the composite end of a composite association is always one to one in this specification, contained instances can only have a single such proxy reference. Date: Wed, 22 Oct 2003 08:39:30 -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: Troublesome paragraph issue from Kevin Jim, I understand this proposed paragraph so that's a plus. No one else appeared to have a problem with this section initially so you might as well leave it in. Thanks for proposing the rewrite. Kevin James Kulp wrote: > > While the problematic paragraph (para 3 in 9.5.8) in the solution to > issue 5959 raised by Kevin could possibly be clarified by the proposed > text below, the first 4 paragraphs of section 9.5.8 are not normative > anyway, but simply elaborate certain flexibilities of the standard XMI > MOF-to-XML-schema mapping. Thus while replacing the paragraph might > help readers understand it, we might want to consider deleting all these > paragraphs since there is no normative content. > > Any opinions about whether to use this (better?) paragraph or nuke all > four of them? > > > Composition associations in UML express that the class at the > > composite end (the containing class) owns and contains the class at > > the part end (the contained class). It is typical, in XML documents, > > for instances of contained classes to be embedded within the instance > > of the containing class. However, it is also possible to store > > contained instances by themselves in a separate file by using a proxy > > (using "href" or "xlink:href") to reference the contained instance in > > a separate file. Since the multiplicity on the composite end of a > > composite association is always one to one in this specification, > > contained instances can only have a single such proxy reference.