Issue 2534: Correct arguments to send multiple requests (c_mapping-rtf) Source: (, ) Nature: Revision Severity: Critical Summary: Summary: Additional Commentary: In tset/c/hdr/DII/ORB/send_multiple_requests.c, VSOrb 1.1.0 test examines our orb on the assumption that send_multiple_requests() is defined like the following. CORBA_Status CORBA_send_multiple_requests( CORBA_ORB orb, CORBA_Request reqs[], CORBA_long count, CORBA_Flags invoke_flags, CORBA_Environment *env ); But, according to section 4.3.2 of CORBA 2.1 specification, send_multiple_requests() is defined like the following. /* C */ CORBA_Status CORBA_send_multiple_requests( CORBA_Request reqs[], CORBA_Environment *env, CORBA_long count, CORBA_Flags invoke_flags ); Section C - Interpretation Responses The Open Group Initial Response: An interpretation from OMG is required to determine whether Section 4.3.2 or Section 17.17 of CORBA 2.1 is definitive. Consultants Initial Response: We believe Section 4.3.2 is incorrect according to the general C mapping rules (as are many of the other examples). We are following rules defined in Section 17.17 which states that every function signature takes the object as the first parameter and an Environment object as the last parameter. Interpretations Subgroup Responses: Resolution: urgent resolution....issue closed Revised Text: Resolution: OMG has determined that Section 17.17 of CORBA 2.1 is definitive. The material in section 4.3.2 will be changed in a future CORBA revision to agree with it. Actions taken: March 12, 1999: received issue August 4, 1999: closed issue Discussion: End of Annotations:===== X-Sender: andrew@emerald.omg.org Date: Fri, 12 Mar 1999 16:39:31 -0500 To: Juergen Boldt , Richard Soley , Jon Siegel From: Andrew Watson Subject: OMG review of req.1.O.00010 [FYI - this one's going to the C mapping RTF as well.] From: Jenny Wilkinson Subject: OMG review of req.1.O.00010 To: ogomgorb@rdg.opengroup.org Date: Fri, 12 Mar 1999 13:41:11 +0000 (GMT) Reply-To: Jenny Wilkinson Precedence: list Date: 12 March 1999 To: ogomgorb@opengroup.org Dear OMG Technical Director (or appointee), In accordance with Section 4.4 of the Policies and Procedures of the OMG Technical Process, this notification is a request for an URGENT clarification of a specific issue. Please direct this to the appropriate RTF, or if no appropriate RTF is currently active, the OMG Architecture Board. As agreed, The Open Group has proposed specific options for the possible clarification. As Technical Director (or his appointee) you are able to propose other specific wording for the clarification to the committee (either the RTF or the AB). The committee is then at liberty to vote on the proposed clarification or to propose other clarifications. The issue for clarification is attached below in the standard Open Group formal interpretation request format which is used in the Open Group anonymous review process. The final clarification by OMG agreeing or disagreeing with the recommended options by the Open Group set out in Section C 'The Open Group Initial Response' will be inserted in the 'Interpretations Subgroup Responses:' part of Section C of the form. The Final Decision reflects this in Section D. The Technical Director or RTF Chair is requested to respond to The Open Group at (ogomgorb@opengroup.org within 10 working days, by 25 March 1999. *********************************************************************** INTERPRETATION REQUEST DOCUMENT TOG Reference: req.1.O.00010 Component: Common Object Request Broker Section B - Interpretation Request Details Version/Release: VSOrb 1.1.0 Testset: tset/c/hdr/DII/ORB/hdr/send_multiple_requests Test No: [required-testnum] Waiver Reason: Grey area in the Specification Reference to previously granted interpretation: [dup-of] Test Results: [required-test-output] Additional Commentary: In tset/c/hdr/DII/ORB/send_multiple_requests.c, VSOrb 1.1.0 test examines our orb on the assumption that send_multiple_requests() is defined like the following. CORBA_Status CORBA_send_multiple_requests( CORBA_ORB orb, CORBA_Request reqs[], CORBA_long count, CORBA_Flags invoke_flags, CORBA_Environment *env ); But, according to section 4.3.2 of CORBA 2.1 specification, send_multiple_requests() is defined like the following. /* C */ CORBA_Status CORBA_send_multiple_requests( CORBA_Request reqs[], CORBA_Environment *env, CORBA_long count, CORBA_Flags invoke_flags ); Section C - Interpretation Responses The Open Group Initial Response: An interpretation from OMG is required to determine whether Section 4.3.2 or Section 17.17 of CORBA 2.1 is definitive. Consultants Initial Response: We believe Section 4.3.2 is incorrect according to the general C mapping rules (as are many of the other examples). We are following rules defined in Section 17.17 which states that every function signature takes the object as the first parameter and an Environment object as the last parameter. Interpretations Subgroup Responses: The Open Group Final Response: ************************************************************************ Jenny Wilkinson T H E Conformance Administrator O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:j.wilkinson@opengroup.org Ph: +44 118 950 8311 x2273 WWW: http://www.opengroup.org Fx: +44 118 950 0110 'Motif, OSF/1, UNIX and the "X Device" are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the US and other countries' ************************************************************************ X-Sender: andrew@emerald.omg.org Date: Fri, 12 Mar 1999 18:03:03 -0500 To: tom_barker@omg.org, c_mapping-rtf@omg.org From: Andrew Watson Subject: Issues 2533 & 2534 classified as urgent Cc: issues@omg.org Dear Tom and members of the C mapping RTF, As you may have seen, we have been sent a couple of clarification requests by The Open Group. We've categorised these as C revision issues and classified them as urgent, which according to section 4.4.1.5 of the P&P means that OMG must respond with a resolution within two weeks. I'm appending the relevant section of the P&P to this message, but broadly speaking, the procedure for urgent resolutions is: 1. Once OMG staff has decided they're urgent issues, they're filed in the ordinary way. 2. Staff provides a proposed resolution (see below). If the RTF for some reason does not come to a decision on resolving the issues, staff submit a resolution, and absent any other contributions, it's likely to be this one. 3. You have two weeks to discuss and vote on a resolution in the normal way. 4. Two weeks from today (Friday 26th March), we will pass back to the Open Group the result of your deliberations (or, in the unlikely event you haven't voted on a resolution, a staff proposal). Here are the staff proposed resolutions: For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that allocating longs in Anys using CORBA_alloc be considered standard (solution 1): any->_type = TC_long; any->_value = CORBA_alloc(sizeof(CORBA_long)); For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the definition of send_multiple_requests() in section 4.3.2 be ruled in error, and be changed to align with the rules section 17.17. If you have any questions on the urgent resolution process, please get in touch with me. Regards, Andrew Andrew Watson Tel: +1 508 820 4300 x111 VP Technology Fax: +1 508 820 4303 Object Management Group, Email: andrew@omg.org 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W Framingham, MA 01701, USA http://www.omg.org/~andrew ----------------------------------------------------------------- 4.4.1.5 Urgent Issues In response to urgent requests for clarifications to a specification ("Urgent Issues"), the OMG shall provide clarifications of specific issues. [Issues may arise that require interpretation or clarification of a specification in a very short period of time. For example, there may be disputes over interpretation during the course of conformance testing in the context of a branding program, or urgent clarifications required by a vendor during product implementation. Resolution needs to occur within a very short period of time (approximately 2 weeks), and should result in modifications on a point-by-point basis.] Urgent Issues shall be directed to the OMG Technical Director (or his appointee), who will determine whether the issue is appropriate for urgent resolution, and if so direct it to the appropriate F/RTF. If no appropriate F/RTF is currently active, the Architecture Board will be responsible for resolving the issue. The Technical Director (or his appointee) will propose specific wording for the clarification to the committee (either the RTF or AB). The committee is then at liberty to vote on the proposed clarification or to propose other clarifications. The issue is deemed closed when a particular clarification has been accepted by a poll of the F/RTF members. If a period of two weeks has passed from the receipt of the issue by the Technical Director and no clarification has been accepted, the Technical Director (or his appointee) will determine an appropriate clarification. [A clarification (in the sense used here) typically eliminates an ambiguity by narrowing the possible interpretations of a specification when there are multiple, incompatible interpretations. In cases where a specification is not logically consistent, a clarification may also render a part of a specification void or add new content, only inasmuch as it is necessary to make the specification consistent. This process must never be used to extend a specification's functionality. The deployment of the Architecture Board in this role is intended as a backstop, a last resort in case an appropriate F/RTF is not active. The Architecture Board should by no means become the "normal" vehicle for resolving issues of this nature. It is the responsibility and duty of the Technology Committees to charter F/RTFs for Adopted and Available Specifications and maintain their readiness to respond as needed. It will most likely be the case that committee discussions and polls on urgent issues will be conducted electronically. OMG staff will maintain appropriate email and document exchange mechanisms to facilitate this process.] Resolutions of Urgent Issues will be formulated and maintained as isolated revisions to the specification, identified by sequential natural numbers and made publicly available. Any clarifications produced by this process shall be incorporated into the final recommendation produced by the F/RTF. Should there not be an appropriate F/RTF, or if the F/RTF does not produce a recommendation before its delivery deadline, any clarifications produced in this manner will automatically and collectively constitute a recommendation of revision. Once a clarification has been accepted, it should not be revisited by the F/RTF during the current revision cycle. [The prohibition against revisiting a clarification is not intended to shackle the F/RTF, but to give clarifications generated by this process some stability. The requirements of branding programs are the primary motivation for this process. An Urgent Issue that alters a branding test suite may affect the implementation of shipping, branded software products, requiring one or more vendors to alter their products to conform to the specification as clarified. It is reasonable for vendors to expect that the clarification will not be arbitrarily reversed simply because the balance of opinion in an F/RTF shifts for some reason (e.g., a change in membership) before its final revision proposal is recommended to the parent Technology Committee. The need for stability is balanced against the need for TC approval. It is possible for the TC to reject the recommendation of an TF (and thus, a set of clarifications), but our assumption is that the TC understands the consequences of such a decision and would only do so under extraordinary circumstances. As an example: If a specification's current revision is numbered 2.1, clarifications will be identified separately, such as "clarification 1 of revision 2.1", and so on. When an F/RTF produces its revision recommendation (either explicitly or by default), the clarifications will be folded into the overall revision, resulting in revision 2.2. If the F/RTF fails to produce a recommendation, OMG staff will collect clarifications into a revision recommendation. ] From: Jeffrey Mischkinsky Subject: Re: Issues 2533 & 2534 classified as urgent To: andrew@omg.org (Andrew Watson) Date: Fri, 12 Mar 1999 16:33:41 -0800 (PST) Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Andrew, It might be helpful in the future if "omg staff", which I suppose is the long-suffering and over-worked person currently manifested as yourself, provided a bit of the rationale for his or her recommendations. I personally agree with your suggestion on #1, and will probably agree with #2, but i have to do my due diligence and go look at the referenced sections first. thx, jeff 'Andrew Watson' writes: > > Dear Tom and members of the C mapping RTF, > > As you may have seen, we have been sent a couple of clarification > requests > by The Open Group. We've categorised these as C revision issues and > classified them as urgent, which according to section 4.4.1.5 of the > P&P > means that OMG must respond with a resolution within two weeks. > > I'm appending the relevant section of the P&P to this message, but > broadly > speaking, the procedure for urgent resolutions is: > > 1. Once OMG staff has decided they're urgent issues, they're filed > in the > ordinary way. > > 2. Staff provides a proposed resolution (see below). If the RTF for > some > reason does not come to a decision on resolving the issues, > staff submit > a resolution, and absent any other contributions, it's likely to > be this > one. > > 3. You have two weeks to discuss and vote on a resolution in the > normal > way. > > 4. Two weeks from today (Friday 26th March), we will pass back to > the Open > Group the result of your deliberations (or, in the unlikely > event you > haven't voted on a resolution, a staff proposal). > > Here are the staff proposed resolutions: > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > allocating longs in Anys using CORBA_alloc be considered standard > (solution > 1): > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that > the > definition of send_multiple_requests() in section 4.3.2 be ruled in > error, > and be changed to align with the rules section 17.17. > > If you have any questions on the urgent resolution process, please > get in > touch with me. > Regards, > > Andrew > Andrew Watson Tel: +1 508 820 4300 > x111 > VP Technology Fax: +1 508 820 4303 > Object Management Group, Email: andrew@omg.org > 492 Old Connecticut Path, Lat/Lon: 42.3122 N > 71.3927 W > Framingham, MA 01701, USA > http://www.omg.org/~andrew > > > ----------------------------------------------------------------- > > 4.4.1.5 Urgent Issues > > In response to urgent requests for clarifications to a specification > ("Urgent Issues"), the OMG shall provide clarifications of specific > issues. > > [Issues may arise that require interpretation or clarification of a > specification in a very short period of time. For example, there may > be > disputes over interpretation during the course of conformance > testing in > the context of a branding program, or urgent clarifications required > by a > vendor during product implementation. Resolution needs to occur > within a > very short period of time (approximately 2 weeks), and should result > in > modifications on a point-by-point basis.] > > Urgent Issues shall be directed to the OMG Technical Director (or > his > appointee), who will determine whether the issue is appropriate for > urgent > resolution, and if so direct it to the appropriate F/RTF. If no > appropriate F/RTF is currently active, the Architecture Board will > be > responsible for resolving the issue. The Technical Director (or his > appointee) will propose specific wording for the clarification to > the > committee (either the RTF or AB). The committee is then at liberty > to vote > on the proposed clarification or to propose other > clarifications. The > issue is deemed closed when a particular clarification has been > accepted > by a poll of the F/RTF members. If a period of two weeks has passed > from > the receipt of the issue by the Technical Director and no > clarification > has been accepted, the Technical Director (or his appointee) will > determine an appropriate clarification. > > [A clarification (in the sense used here) typically eliminates an > ambiguity by narrowing the possible interpretations of a > specification > when there are multiple, incompatible interpretations. In cases > where a > specification is not logically consistent, a clarification may also > render > a part of a specification void or add new content, only inasmuch as > it is > necessary to make the specification consistent. This process must > never be > used to extend a specification's functionality. > > The deployment of the Architecture Board in this role is intended as > a > backstop, a last resort in case an appropriate F/RTF is not > active. The > Architecture Board should by no means become the "normal" vehicle > for > resolving issues of this nature. It is the responsibility and duty > of the > Technology Committees to charter F/RTFs for Adopted and Available > Specifications and maintain their readiness to respond as needed. > > It will most likely be the case that committee discussions and polls > on > urgent issues will be conducted electronically. OMG staff will > maintain > appropriate email and document exchange mechanisms to facilitate > this > process.] > > Resolutions of Urgent Issues will be formulated and maintained as > isolated > revisions to the specification, identified by sequential natural > numbers > and made publicly available. Any clarifications produced by this > process > shall be incorporated into the final recommendation produced by the > F/RTF. > Should there not be an appropriate F/RTF, or if the F/RTF does not > produce > a recommendation before its delivery deadline, any clarifications > produced > in this manner will automatically and collectively constitute a > recommendation of revision. Once a clarification has been accepted, > it > should not be revisited by the F/RTF during the current revision > cycle. > > [The prohibition against revisiting a clarification is not intended > to > shackle the F/RTF, but to give clarifications generated by this > process > some stability. The requirements of branding programs are the > primary > motivation for this process. An Urgent Issue that alters a branding > test > suite may affect the implementation of shipping, branded software > products, requiring one or more vendors to alter their products to > conform > to the specification as clarified. It is reasonable for vendors to > expect > that the clarification will not be arbitrarily reversed simply > because the > balance of opinion in an F/RTF shifts for some reason (e.g., a > change in > membership) before its final revision proposal is recommended to the > parent Technology Committee. The need for stability is balanced > against > the need for TC approval. It is possible for the TC to reject the > recommendation of an TF (and thus, a set of clarifications), but our > assumption is that the TC understands the consequences of such a > decision > and would only do so under extraordinary circumstances. > > As an example: If a specification's current revision is numbered > 2.1, > clarifications will be identified separately, such as "clarification > 1 of > revision 2.1", and so on. When an F/RTF produces its revision > recommendation (either explicitly or by default), the clarifications > will > be folded into the overall revision, resulting in revision 2.2. If > the > F/RTF fails to produce a recommendation, OMG staff will collect > clarifications into a revision recommendation. ] > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Content-return: allowed Date: Mon, 15 Mar 1999 08:53:49 -0500 From: "Barker, Thomas" Subject: RE: Issues 2533 & 2534 classified as urgent To: "'Andrew Watson'" , tom_barker@omg.org, c_mapping-rtf@omg.org Cc: issues@omg.org Issues 309, 322 and 323 also relate to this question. Lets plan on covering them all and voting in the changes to 19.8 by 3/24. I'm considering the changes as they are applicable to CORBA v2.2. I don't even know where to find the copy of v2.1. Section 4.3.2 was in the old spec and the v2.2 spec does not have the same number. Does anybody know where that section moved? > -----Original Message----- > From: Andrew Watson [SMTP:andrew@omg.org] > Sent: Friday, March 12, 1999 6:03 PM > To: tom_barker@omg.org; c_mapping-rtf@omg.org > Cc: issues@omg.org > Subject: Issues 2533 & 2534 classified as urgent > > Dear Tom and members of the C mapping RTF, > > As you may have seen, we have been sent a couple of clarification > requests > by The Open Group. We've categorised these as C revision issues and > classified them as urgent, which according to section 4.4.1.5 of the > P&P > means that OMG must respond with a resolution within two weeks. > > I'm appending the relevant section of the P&P to this message, but > broadly > speaking, the procedure for urgent resolutions is: > > 1. Once OMG staff has decided they're urgent issues, they're filed > in the > ordinary way. > > 2. Staff provides a proposed resolution (see below). If the RTF for > some > reason does not come to a decision on resolving the issues, > staff > submit > a resolution, and absent any other contributions, it's likely to > be > this > one. > > 3. You have two weeks to discuss and vote on a resolution in the > normal > way. > > 4. Two weeks from today (Friday 26th March), we will pass back to > the > Open > Group the result of your deliberations (or, in the unlikely > event you > haven't voted on a resolution, a staff proposal). > > Here are the staff proposed resolutions: > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > allocating longs in Anys using CORBA_alloc be considered standard > (solution > 1): > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that > the > definition of send_multiple_requests() in section 4.3.2 be ruled in > error, > and be changed to align with the rules section 17.17. > > If you have any questions on the urgent resolution process, please > get in > touch with me. > Regards, > > Andrew > Andrew Watson Tel: +1 508 820 4300 > x111 > VP Technology Fax: +1 508 820 4303 > Object Management Group, Email: andrew@omg.org > 492 Old Connecticut Path, Lat/Lon: 42.3122 N > 71.3927 W > Framingham, MA 01701, USA > http://www.omg.org/~andrew > > > ----------------------------------------------------------------- > > 4.4.1.5 Urgent Issues > > In response to urgent requests for clarifications to a specification > ("Urgent Issues"), the OMG shall provide clarifications of specific > issues. > > [Issues may arise that require interpretation or clarification of a > specification in a very short period of time. For example, there may > be > disputes over interpretation during the course of conformance > testing in > the context of a branding program, or urgent clarifications required > by a > vendor during product implementation. Resolution needs to occur > within a > very short period of time (approximately 2 weeks), and should result > in > modifications on a point-by-point basis.] > > Urgent Issues shall be directed to the OMG Technical Director (or > his > appointee), who will determine whether the issue is appropriate for > urgent > resolution, and if so direct it to the appropriate F/RTF. If no > appropriate F/RTF is currently active, the Architecture Board will > be > responsible for resolving the issue. The Technical Director (or his > appointee) will propose specific wording for the clarification to > the > committee (either the RTF or AB). The committee is then at liberty > to vote > on the proposed clarification or to propose other > clarifications. The > issue is deemed closed when a particular clarification has been > accepted > by a poll of the F/RTF members. If a period of two weeks has passed > from > the receipt of the issue by the Technical Director and no > clarification > has been accepted, the Technical Director (or his appointee) will > determine an appropriate clarification. > > [A clarification (in the sense used here) typically eliminates an > ambiguity by narrowing the possible interpretations of a > specification > when there are multiple, incompatible interpretations. In cases > where a > specification is not logically consistent, a clarification may also > render > a part of a specification void or add new content, only inasmuch as > it is > necessary to make the specification consistent. This process must > never be > used to extend a specification's functionality. > > The deployment of the Architecture Board in this role is intended as > a > backstop, a last resort in case an appropriate F/RTF is not > active. The > Architecture Board should by no means become the "normal" vehicle > for > resolving issues of this nature. It is the responsibility and duty > of the > Technology Committees to charter F/RTFs for Adopted and Available > Specifications and maintain their readiness to respond as needed. > > It will most likely be the case that committee discussions and polls > on > urgent issues will be conducted electronically. OMG staff will > maintain > appropriate email and document exchange mechanisms to facilitate > this > process.] > > Resolutions of Urgent Issues will be formulated and maintained as > isolated > revisions to the specification, identified by sequential natural > numbers > and made publicly available. Any clarifications produced by this > process > shall be incorporated into the final recommendation produced by the > F/RTF. > Should there not be an appropriate F/RTF, or if the F/RTF does not > produce > a recommendation before its delivery deadline, any clarifications > produced > in this manner will automatically and collectively constitute a > recommendation of revision. Once a clarification has been accepted, > it > should not be revisited by the F/RTF during the current revision > cycle. > > [The prohibition against revisiting a clarification is not intended > to > shackle the F/RTF, but to give clarifications generated by this > process > some stability. The requirements of branding programs are the > primary > motivation for this process. An Urgent Issue that alters a branding > test > suite may affect the implementation of shipping, branded software > products, requiring one or more vendors to alter their products to > conform > to the specification as clarified. It is reasonable for vendors to > expect > that the clarification will not be arbitrarily reversed simply > because the > balance of opinion in an F/RTF shifts for some reason (e.g., a > change in > membership) before its final revision proposal is recommended to the > parent Technology Committee. The need for stability is balanced > against > the need for TC approval. It is possible for the TC to reject the > recommendation of an TF (and thus, a set of clarifications), but our > assumption is that the TC understands the consequences of such a > decision > and would only do so under extraordinary circumstances. > > As an example: If a specification's current revision is numbered > 2.1, > clarifications will be identified separately, such as "clarification > 1 of > revision 2.1", and so on. When an F/RTF produces its revision > recommendation (either explicitly or by default), the clarifications > will > be folded into the overall revision, resulting in revision 2.2. If > the > F/RTF fails to produce a recommendation, OMG staff will collect > clarifications into a revision recommendation. ] > X-Sender: siegel@192.67.184.65 Date: Mon, 15 Mar 1999 09:47:51 -0500 To: "Barker, Thomas" From: Jon Siegel Subject: RE: Issues 2533 & 2534 classified as urgent Cc: "'Andrew Watson'" , tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Hi, all -- The old specs are archived in the "formal" subdirectory of the document directory. To get at everything, go to http://www.omg.org/cgi-bin/members/doclistm.pl log in, and select "formal" in the "select subgroups" box and search for "2.1". You'll find ... The docs you want are availble as either formal/97-11-04: CORBA 2.1 with change bars (Contact: Mr. Juergen Boldt) No description of this document is available. Formats: Gzipped PostScript, PostScript, PDF formal/97-11-03: CORBA 2.1 without change bars (Contact: Mr. Juergen Boldt) No description of this document is available. Formats: Gzipped PostScript, PostScript, PDF Enjoy -- Jon Siegel OMG At 08:53 AM 3/15/99 -0500, Barker, Thomas wrote: >Issues 309, 322 and 323 also relate to this question. Lets plan on covering >them all and voting in the changes to 19.8 by 3/24. > >I'm considering the changes as they are applicable to CORBA v2.2. I don't >even know where to find the copy of v2.1. Section 4.3.2 was in the old spec >and the v2.2 spec does not have the same number. Does anybody know where >that section moved? > >> -----Original Message----- >> From: Andrew Watson [SMTP:andrew@omg.org] >> Sent: Friday, March 12, 1999 6:03 PM >> To: tom_barker@omg.org; c_mapping-rtf@omg.org >> Cc: issues@omg.org >> Subject: Issues 2533 & 2534 classified as urgent >> >> Dear Tom and members of the C mapping RTF, >> >> As you may have seen, we have been sent a couple of clarification requests >> by The Open Group. We've categorised these as C revision issues and >> classified them as urgent, which according to section 4.4.1.5 of the P&P >> means that OMG must respond with a resolution within two weeks. >> >> I'm appending the relevant section of the P&P to this message, but broadly >> speaking, the procedure for urgent resolutions is: >> >> 1. Once OMG staff has decided they're urgent issues, they're filed in the >> ordinary way. >> >> 2. Staff provides a proposed resolution (see below). If the RTF for some >> reason does not come to a decision on resolving the issues, staff >> submit >> a resolution, and absent any other contributions, it's likely to be >> this >> one. >> >> 3. You have two weeks to discuss and vote on a resolution in the normal >> way. >> >> 4. Two weeks from today (Friday 26th March), we will pass back to the >> Open >> Group the result of your deliberations (or, in the unlikely event you >> haven't voted on a resolution, a staff proposal). >> >> Here are the staff proposed resolutions: >> >> For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that >> allocating longs in Anys using CORBA_alloc be considered standard >> (solution >> 1): >> >> any->_type = TC_long; >> any->_value = CORBA_alloc(sizeof(CORBA_long)); >> >> For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the >> definition of send_multiple_requests() in section 4.3.2 be ruled in error, >> and be changed to align with the rules section 17.17. >> >> If you have any questions on the urgent resolution process, please get in >> touch with me. >> Regards, >> >> Andrew >> Andrew Watson Tel: +1 508 820 4300 x111 >> VP Technology Fax: +1 508 820 4303 >> Object Management Group, Email: andrew@omg.org >> 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W >> Framingham, MA 01701, USA http://www.omg.org/~andrew >> >> ----------------------------------------------------------------- >> >> 4.4.1.5 Urgent Issues >> >> In response to urgent requests for clarifications to a specification >> ("Urgent Issues"), the OMG shall provide clarifications of specific >> issues. >> >> [Issues may arise that require interpretation or clarification of a >> specification in a very short period of time. For example, there may be >> disputes over interpretation during the course of conformance testing in >> the context of a branding program, or urgent clarifications required by a >> vendor during product implementation. Resolution needs to occur within a >> very short period of time (approximately 2 weeks), and should result in >> modifications on a point-by-point basis.] >> >> Urgent Issues shall be directed to the OMG Technical Director (or his >> appointee), who will determine whether the issue is appropriate for urgent >> resolution, and if so direct it to the appropriate F/RTF. If no >> appropriate F/RTF is currently active, the Architecture Board will be >> responsible for resolving the issue. The Technical Director (or his >> appointee) will propose specific wording for the clarification to the >> committee (either the RTF or AB). The committee is then at liberty to vote >> on the proposed clarification or to propose other clarifications. The >> issue is deemed closed when a particular clarification has been accepted >> by a poll of the F/RTF members. If a period of two weeks has passed from >> the receipt of the issue by the Technical Director and no clarification >> has been accepted, the Technical Director (or his appointee) will >> determine an appropriate clarification. >> >> [A clarification (in the sense used here) typically eliminates an >> ambiguity by narrowing the possible interpretations of a specification >> when there are multiple, incompatible interpretations. In cases where a >> specification is not logically consistent, a clarification may also render >> a part of a specification void or add new content, only inasmuch as it is >> necessary to make the specification consistent. This process must never be >> used to extend a specification's functionality. >> >> The deployment of the Architecture Board in this role is intended as a >> backstop, a last resort in case an appropriate F/RTF is not active. The >> Architecture Board should by no means become the "normal" vehicle for >> resolving issues of this nature. It is the responsibility and duty of the >> Technology Committees to charter F/RTFs for Adopted and Available >> Specifications and maintain their readiness to respond as needed. >> >> It will most likely be the case that committee discussions and polls on >> urgent issues will be conducted electronically. OMG staff will maintain >> appropriate email and document exchange mechanisms to facilitate this >> process.] >> >> Resolutions of Urgent Issues will be formulated and maintained as isolated >> revisions to the specification, identified by sequential natural numbers >> and made publicly available. Any clarifications produced by this process >> shall be incorporated into the final recommendation produced by the F/RTF. >> Should there not be an appropriate F/RTF, or if the F/RTF does not produce >> a recommendation before its delivery deadline, any clarifications produced >> in this manner will automatically and collectively constitute a >> recommendation of revision. Once a clarification has been accepted, it >> should not be revisited by the F/RTF during the current revision cycle. >> >> [The prohibition against revisiting a clarification is not intended to >> shackle the F/RTF, but to give clarifications generated by this process >> some stability. The requirements of branding programs are the primary >> motivation for this process. An Urgent Issue that alters a branding test >> suite may affect the implementation of shipping, branded software >> products, requiring one or more vendors to alter their products to conform >> to the specification as clarified. It is reasonable for vendors to expect >> that the clarification will not be arbitrarily reversed simply because the >> balance of opinion in an F/RTF shifts for some reason (e.g., a change in >> membership) before its final revision proposal is recommended to the >> parent Technology Committee. The need for stability is balanced against >> the need for TC approval. It is possible for the TC to reject the >> recommendation of an TF (and thus, a set of clarifications), but our >> assumption is that the TC understands the consequences of such a decision >> and would only do so under extraordinary circumstances. >> >> As an example: If a specification's current revision is numbered 2.1, >> clarifications will be identified separately, such as "clarification 1 of >> revision 2.1", and so on. When an F/RTF produces its revision >> recommendation (either explicitly or by default), the clarifications will >> be folded into the overall revision, resulting in revision 2.2. If the >> F/RTF fails to produce a recommendation, OMG staff will collect >> clarifications into a revision recommendation. ] >> > > ================================================================== Jon Siegel Phone: 508-820-4300 X124 Director, Domain Technology Fax: 508-820-4303 Object Management Group 492 Old Connecticut Path email: siegel@omg.org Framingham, Massachusetts 01701 USA http://www.omg.org ================================================================== X-Sender: andrew@emerald.omg.org Date: Mon, 15 Mar 1999 11:06:23 -0500 To: "Barker, Thomas" From: Andrew Watson Subject: RE: Issues 2533 & 2534 classified as urgent Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org, Linda Heaton Tom, You wrote: > Issues 309, 322 and 323 also relate to this question. Lets plan on > covering them all and voting in the changes to 19.8 by 3/24. I'm glad to see that this isn't the first time this has been noticed! > I'm considering the changes as they are applicable to CORBA v2.2. I don't > even know where to find the copy of v2.1. Section 4.3.2 was in the old > spec and the v2.2 spec does not have the same number. Does anybody know > where that section moved? You can get hold of copies of the 2.1 specification from these URLs: http://www.omg.org/cgi-bin/doc?formal/97-11-04 CORBA 2.1 with change bars http://www.omg.org/cgi-bin/doc?formal/97-11-03 CORBA 2.1 (no change bars) While you're looking at this, I'd recommend checking whether this problem was propogated to 2.2 and to the forthcoming 2.3 spec. [Linda - please can you work with Tom to check whether these problems with the C mapping chapter in 2.1 are still there in 2.3? Thanks.] Cheers, Andrew X-Sender: andrew@emerald.omg.org References: from "Andrew Watson" at Mar 12, 99 06:03:03 pm Date: Mon, 15 Mar 1999 10:55:48 -0500 To: Jeffrey Mischkinsky From: Andrew Watson Subject: Re: Issues 2533 & 2534 classified as urgent Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Jeff, You wrote: > It might be helpful in the future if "omg staff", which I suppose is the > long-suffering and over-worked person currently manifested as yourself, > provided a bit of the rationale for his or her recommendations. So you want to know what denomination of coin I tossed to decide? :-) But seriously ... I think perhaps "recommendation" is probably the wrong word for this - "threat" or "fair warning" might be closer to the mark. In the unlikely event that we have a delinquent or deadlocked RTF which fails to make a decision within the two weeks, the Technical Director steps into the breach and sends back a resolution - by including a proposed resolution in the notification, I'm giving the RTF fair warning of what will (probably) be the OMG reply if they don't respond. Of course, this means that if I want to make sure the RTF takes the decision (and I do!), then I should probably pick the least-useful, most-disruptive interpretation as the default, so that the RTF has an incentive to override it :-). AFAIK I haven't this time, but you have been warned! > I personally agree with your suggestion on #1, and will probably agree > with #2, but i have to do my due diligence and go look at the referenced > sections first. I would expect no less! Cheers, Andrew Sender: jis@fpk.hp.com Date: Mon, 15 Mar 1999 12:07:38 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL To: Andrew Watson CC: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Subject: Re: Issues 2533 & 2534 classified as urgent References: > Here are the staff proposed resolutions: > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > allocating longs in Anys using CORBA_alloc be considered standard > (solution > 1): > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); I agree with the staff position on this one. > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the > definition of send_multiple_requests() in section 4.3.2 be ruled in error, > and be changed to align with the rules section 17.17. First of all what used to be section 4.3.2 is now section 7.3.2. and what used to be 17.17 is now somewhere in the 20's probably.:-) 1. The envp parameter belongs in the end of the parameter list. This was fixed in the DII chapter in Core RTF 2.3. 2. Actually, one could argue that VSOrb is wrong in assuming that send_multiple_requests is an ORB operation. Apparently they assume this since they place the ORB as the first argument. It never has been part of the ORB interface in chapter 4. Certain language mappings have placed it in the ORB class (e.g. C++), and this may very well be the time to change the C mapping so as to make it look like it is part of the ORB interface. But in the originally adopted CORBA, for reasons that are not very clear to me, the two functions send_multiple_requests and get_next_response were deliberately not made part of the ORB interface. Maybe our C ORB expert Dan Frantz can shed some light on this matter. So, on point 2 I have a problem blessing an interpretation that is clearly a signifcant (and not very necessary) change in 2.1, which may have consequences in other language mappings like COBOL and Smalltalk, and in deployed C ORBs. Of course if all deployed C ORBs are OK with this then that makes the case stronger for accepting this as the way to go in the conformance testing tool, and to fix the spec.:-) So until I hear some more rationale I am going to vote a partial NO on the staff recommendation on issue 2534. Partial, because envp should be the last paramter (The partial YES) and there should be no orb argument (the NO part). So what say you Oh Gurus of ORB-dome? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Content-return: allowed Date: Mon, 15 Mar 1999 14:50:42 -0500 From: "Barker, Thomas" Subject: RE: Issues 2533 & 2534 classified as urgent To: "'Jishnu Mukerji'" , Andrew Watson Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Issue staff solution to 2533 seems agreeable to all. It would take a new paragraph in the v2.2 Section 19.8. I'll draft one and send it out for comment this evening or Wed (unless someone else wants to do it. I have to travel tomorrow.) On 2534 I sort of agree with staff that the v2.1 Section 4.3.2 (it became v2.2 Section 5.3.2) is wrong but I don't see the same error that Jishnu sees. Why should the send_multiple_requests operation be defined by giving a C and Smalltalk example. If it was defined using PIDL then normal language mapping chapters would handle the subtleties of each language. The question of whether it belongs to the ORB or not seems independent. > -----Original Message----- > From: Jishnu Mukerji [SMTP:jis@fpk.hp.com] > Sent: Monday, March 15, 1999 12:08 PM > To: Andrew Watson > Cc: tom_barker@omg.org; c_mapping-rtf@omg.org; issues@omg.org > Subject: Re: Issues 2533 & 2534 classified as urgent > > > Here are the staff proposed resolutions: > > > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > > allocating longs in Anys using CORBA_alloc be considered standard > (solution > > 1): > > > > any->_type = TC_long; > > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > I agree with the staff position on this one. > > > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that > the > > definition of send_multiple_requests() in section 4.3.2 be ruled > in > error, > > and be changed to align with the rules section 17.17. > > First of all what used to be section 4.3.2 is now section 7.3.2. and > what used to be 17.17 is now somewhere in the 20's probably.:-) > > 1. The envp parameter belongs in the end of the parameter list. This > was > fixed in the DII chapter in Core RTF 2.3. > > 2. Actually, one could argue that VSOrb is wrong in assuming that > send_multiple_requests is an ORB operation. Apparently they assume > this > since they place the ORB as the first argument. It never has been > part > of the ORB interface in chapter 4. Certain language mappings have > placed > it in the ORB class (e.g. C++), and this may very well be the time > to > change the C mapping so as to make it look like it is part of the > ORB > interface. But in the originally adopted CORBA, for reasons that are > not > very clear to me, the two functions send_multiple_requests and > get_next_response were deliberately not made part of the ORB > interface. > Maybe our C ORB expert Dan Frantz can shed some light on this > matter. > > So, on point 2 I have a problem blessing an interpretation that is > clearly a signifcant (and not very necessary) change in 2.1, which > may > have consequences in other language mappings like COBOL and > Smalltalk, > and in deployed C ORBs. Of course if all deployed C ORBs are OK with > this then that makes the case stronger for accepting this as the way > to > go in the conformance testing tool, and to fix the spec.:-) > > So until I hear some more rationale I am going to vote a partial NO > on > the staff recommendation on issue 2534. Partial, because envp should > be > the last paramter (The partial YES) and there should be no orb > argument > (the NO part). > > So what say you Oh Gurus of ORB-dome? > > Jishnu. > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-My-Real-Login-Name: sugino; 10.35.109.43 Date: Tue, 16 Mar 1999 19:03:55 +0900 From: Yasuaki Sugino To: Jishnu Mukerji , Andrew Watson Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org References: <36ED3E5A.DBDC97C0@fpk.hp.com> Subject: Re^2: Issues 2533 & 2534 classified as urgent Hi members, I would like to join this discussion on 2534. Jishnu Mukerji , Andrew Watson wrote Mon, 15 Mar 1999 12:07:38 -0500 Subject: "Re: Issues 2533 & 2534 classified as urgent" Jishnu> > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the Jishnu> > definition of send_multiple_requests() in section 4.3.2 be ruled in error, Jishnu> > and be changed to align with the rules section 17.17. Jishnu> Jishnu> First of all what used to be section 4.3.2 is now section 7.3.2. and Jishnu> what used to be 17.17 is now somewhere in the 20's probably.:-) Jishnu> Jishnu> 1. The envp parameter belongs in the end of the parameter list. This was Jishnu> fixed in the DII chapter in Core RTF 2.3. Jishnu> Jishnu> 2. Actually, one could argue that VSOrb is wrong in assuming that Jishnu> send_multiple_requests is an ORB operation. Apparently they assume this Jishnu> since they place the ORB as the first argument. It never has been part Jishnu> of the ORB interface in chapter 4. Certain language mappings have placed Jishnu> it in the ORB class (e.g. C++), and this may very well be the time to Jishnu> change the C mapping so as to make it look like it is part of the ORB Jishnu> interface. But in the originally adopted CORBA, for reasons that are not Jishnu> very clear to me, the two functions send_multiple_requests and Jishnu> get_next_response were deliberately not made part of the ORB interface. Jishnu> Maybe our C ORB expert Dan Frantz can shed some light on this matter. Jishnu> Jishnu> So, on point 2 I have a problem blessing an interpretation that is Jishnu> clearly a signifcant (and not very necessary) change in 2.1, which may Jishnu> have consequences in other language mappings like COBOL and Smalltalk, Jishnu> and in deployed C ORBs. Of course if all deployed C ORBs are OK with Jishnu> this then that makes the case stronger for accepting this as the way to Jishnu> go in the conformance testing tool, and to fix the spec.:-) At least, our ORB are OK with it.:-) By the way,I discussed with our CORBA ORB developers on 2534. As the result of our discussion, we believe that send_multiple_requests() should not modified in same CORBA interface to keep consistences in CORBA specification and backward compatibility. Instead of it, we suggest that send_multiple_requests() should move into ORB interface and be fixed. Of course, get_next_response() also should move into ORB interface. And I think "CORBA::send_multiple_requests()" and "CORBA::get_next_response()"can be non-recommened methods in future CORBA specification. ----- Best Regards Yasuaki SUGINO FUJITSU LIMITED X-Sender: andrew@emerald.omg.org Date: Fri, 26 Mar 1999 00:29:39 -0500 To: Jenny Wilkinson From: Andrew Watson Subject: Re: OMG review of req.1.O.00010 (OMG issue 2534) Cc: ogomgorb@opengroup.org, issues@omg.org, c_mapping-rtf@omg.org Jenny, You wrote: > INTERPRETATION REQUEST DOCUMENT TOG Reference: req.1.O.00010 Here is the OMG reply to your interpretation request: > In tset/c/hdr/DII/ORB/send_multiple_requests.c, > VSOrb 1.1.0 test examines our orb on the assumption that > send_multiple_requests() is defined like the following. > > CORBA_Status CORBA_send_multiple_requests( > CORBA_ORB orb, > CORBA_Request reqs[], > CORBA_long count, > CORBA_Flags invoke_flags, > CORBA_Environment *env > ); > > But, according to section 4.3.2 of CORBA 2.1 specification, > send_multiple_requests() is defined like the following. > > /* C */ > CORBA_Status CORBA_send_multiple_requests( > CORBA_Request reqs[], > CORBA_Environment *env, > CORBA_long count, > CORBA_Flags invoke_flags > ); > > Section C - Interpretation Responses > > The Open Group Initial Response: > An interpretation from OMG is required to determine whether > Section > 4.3.2 or Section 17.17 of CORBA 2.1 is definitive. > > Consultants Initial Response: > We believe Section 4.3.2 is incorrect according to the general > C mapping rules (as are many of the other examples). We are > following rules defined in Section 17.17 which states that > every > function signature takes the object as the first parameter and > an > Environment object as the last parameter. OMG has determined that Section 17.17 of CORBA 2.1 is definitive. The material in section 4.3.2 will be changed in a future CORBA revision to agree with it. Regards, Andrew Andrew Watson Tel: +1 508 820 4300 x111 VP Technology Fax: +1 508 820 4303 Object Management Group, Email: andrew@omg.org 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W Framingham, MA 01701, USA http://www.omg.org/~andrew