Issue 4329: "supports" terminology issue for CCM (components-ftf) Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org) Nature: Uncategorized Issue Severity: Summary: . I don't think OMG specifications should use a single term in two distinctly different ways. The text of the issue starts with the sentence, "the Components spec and valuetype spec treat "supports" exactly **OPPOSITE** in semantics regarding widening/narrowing." and continues for about 3 or 4 paragraphs. Ed's comment should go in there too. Resolution: rejected Revised Text: Actions taken: May 18, 2001: received issue May 13, 2002: closed issue Discussion: It seems to be agreed that the issue is not a technical one, as the usage of "supports" for components is, in syntax and semantics, the same as for valuetypes: the component/valuetype will offer all operations and attributes from the supported interface. In both cases, "true" inheritance is not used because inheritance should only be used within the same type hierarchy. The difference with respect to widening is a side effect of using interface inheritance for supported interfaces in equivalent IDL, and this is not easy to avoid. The CCM FTF strongly opposes introducing a new keyword instead of "supports" here. End of Annotations:===== X-Sender: siegel@192.67.184.65 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 May 2001 15:18:26 -0400 To: Edward Cobb , components-ftf@omg.org, ccm@eurescom.de, issues@omg.org, Juergen Boldt From: Jon Siegel Subject: "supports" terminology issue for CCM In-Reply-To: <5.0.0.25.2.20010518094624.00a62eb0@santa-clara.beasys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ``_!!'63e9$"?!!17G!! Hi All -- I'd like to make this a CCM issue, unless anyone objects. I don't think OMG specifications should use a single term in two distinctly different ways. The text of the issue starts with the sentence, "the Components spec and valuetype spec treat "supports" exactly **OPPOSITE** in semantics regarding widening/narrowing." and continues for about 3 or 4 paragraphs. Ed's comment should go in there too. Juergen, if you don't receive any objections by, say, end of day Monday, please file this as an issue against the CCM. Jon Siegel OMG At 09:47 AM 5/18/01 -0700, Edward Cobb wrote: >> It seems that Jon and I had this conversation somewhere in the world in the past year... >> Since the meaning of supports in the CCM spec specifies that the supported interface actually inherits from the component interface, it follows that one can narrow a component interface to a supported interface. If that is not true with the current semantics of supports with regards to valuetypes, then it would make sense for the FTF to rename the supports keyword in CCM to something else. >> >>At 10:06 AM 5/16/01 -0400, Jon Siegel wrote: >>>Hi all -- >>> >>>Sorry about the confusion. I've done a little more research and >>>it's even more confusing than I originally thought: the >>>Components spec and valuetype spec treat "supports" exactly >>>**OPPOSITE** in semantics regarding widening/narrowing. >>> >>>The Component spec *requires* widening/narrowing of a component >>>to it>>> >>>In contrast, the valuetype specification specifically **PROHIBITS** >>>narrowing/widening between interface and valuetype, including the >>>case >>>from a valuetype to its supported type, as stated in this paragraph >>> >>>from page 5-6 of CORBA 2.4.1: >>> >>>5.2.6 Widening/Narrowing >>>As has been described above, value type instances may be >>>widened/narrowed to other >>>value types. Each language mapping is responsible for specifying >>>how these operations >>>are made available to the programmer. >>>Narrowing from an interface type instance to a value type instance >>>is not allowed. If >>>the interface designer wants to allow the receiving context to >>>create a local >>>implementation of the value type (i.e., a value representing the >>>interface) an operation >>>that returns the appropriate value type may be defined. >>> >>>This is enough confusion for me. I'd suggest that you folks fix >>>the terminology to make "supports" either consistent between >>>valuetypes and Components, or replace the Component "supports" >>>keyword with another word. You can't change the meaning of >>>"supports" >>>for valuetypes since it's been in the CORBA spec for so long. >>> >>>There doesn't seem to be any problem with use of the term >>>"provides". >>> >>>This isn't OMG talking; it's just me. >>> >>>Thanks -- >>> >>>Jon Siegel >>> >>>At 08:54 AM 5/16/01 -0400, Jean-Christophe Dubois wrote: >>>>Hello John, >>>> >>>>I am a bit confuse by your statement below. >>>> >>>>My understanding was that component could inherit only from other >>>component >>>>(not interfaces) but can additionaly support interfaces on their >>>equivalent >>>>interface. This translate in IDL 2.X in a (component) interface >>>that inherit >>>>from both the inherited components (or CCMObject if none was >>>provided) and >>>>the supported interfaces. >>>> >>>>Therefore the IDL2.X code will allow the narrowing of the >>>component >>>>reference to the supported interface. >>>> >>>>If this was not the case how would a client acquire a reference to >>>the >>>>"supported" interface? >>>> >>>>Am I missing something? >>>> >>>>Regards >>>> >>>>JC >>>> >>>>----- Original Message ----- >>>>From: "Jon Siegel" >>>>To: "Raphael Marvie" ; "Frank Pilhofer" >>> >>>>Cc: "Olaf Kath" ; >>>; >>>>; >>>>Sent: Wednesday, May 16, 2001 8:25 AM >>>>Subject: Re: OMG CCM meeting minutes >>>> >>>> >>>>Hi all -- >>>> >>>>I have a little information on "supports" that may help here. >>>>Sorry but I haven't done any research on "provides". I'm pretty >>>>sure that I have my basic facts straight here but experts may be >>>>able to help with details. >>>> >>>>"supports" was added to OMG's vocabulary with valuetypes to allow >>>>them to provide the functionality of an interface *without* >>>>mixing it into their inheritance hierarchy. This ensures that it >>>is >>>>impossible to move between valuetypes and CORBA objects when you >>>>narrow or widen a reference's type. If it had been possible to >>>>do this, applications would be able to pass a valuetype by value >>>>to an application that was expecting only a CORBA object >>>reference, >>>>by injudicious use of narrow to convert. >>>> >>>>So, if you say that a Component type "supports" a CORBA >>>>interface, the narrow operation will not convert a Component >>>>reference to the supported CORBA object type, whereas if you had >>>>coded in your IDL (or CIDL) that the Component type inherited the >>>>CORBA interface, you would be able to move between the two types >>>>in this way. >>>> >>>>I guess the bottom line is this: If Component types and CORBA >>>>types are *truly* interchangeable, use "inherit" (or just call >>>them all >>>>CORBA objects!); if they're not, use "supports". >>>> >>>>Does this help? Does anyone want to clarify parts of this? >>>> >>>>Thanks -- >>>> >>>>Jon Siegel >>>>OMG >>>> >>>> >>>>At 01:45 PM 5/16/01 +0200, Raphael Marvie wrote: >>>>>Frank Pilhofer writes: >>>>>> > >>>>>> > Providing that, how will it then be possible to define the >>>segmentation >>>>>> > of an implementation ??? >>>>>> > >>>>>> >>>>>> By either making components support an interface (monolithic >>>>implementation) >>>>>> or by making components provide an interface (segmented or >>>remote >>>>implemen- >>>>>> tation). This is equivalent to the choice of inheriting an >>>interface or >>>>>> providing an object reference in normal POA programming. >>>>>> >>>>>> I always thought that it does not make sense to have both >>>"supports" and >>>>>> "provides" if there's no semantic difference between them. >>>>> >>>>>Well I do not agree this last one. The difference is that the use >>>of a >>>>>reference related to a `provides' comes with operations to manage >>>its >>>>>connectivity : it is really a port. A supported interface only >>>>>enriches the base interface of the component, it does not define >>>how >>>>>the reference should be used. >>>>> >>>>>I understand that the structure of the implementation may or may >>>not >>>>>vary from one to the other, however in terms of concepts they are >>>>>completely different. Support is a means to keep traditional >>>CORBA 2 >>>>>inheritance, not provides. Even if both are implemented the same >>>way >>>>>it does not mean that they are idenitical in the model. >>>>> >>>>>Finally, I would say that `support' should be used to categorize >>>(*) a >>>>>component while `provides' should be used to define services >>>provided >>>>>by a component. I think that operations coming from a support >>>should >>>>>not be functional ones, only operations related to management and >>>>>administration of the component. (I do not say that one should >>>not >>>>>define a port for administration purpose, which is a good >>>approach to >>>>>me). >>>>> >>>>>(*) And this could be an answer to the specification of the kind >>>of >>>>>component in IDL3. The interface defining the component type >>>could be >>>>>specified in the definition of the component using the support >>>>>keyword. It is not as clean as using a meta-model fo the CIF >>>which is >>>>>important, however it rovides a quick answer to this problem that >>>may >>>>>be modified through a RFP in the future if we cannot find a good >>>>>solution for september. >>>>> >>>>>component MyComponent supports SessionComponent { >>>>> // ... >>>>>} ; >>>>> >>>>>The problem here is that one component type could not change from >>>>>Session to Service depending on the context and the >>>implementation as >>>>>it would using CIDL. A solution is to introduce an inheritance >>>level, >>>>>but it multiplies the number of component type definitions. >>>>> >>>>>component MyComponent { >>>>> // ... >>>>>} ; >>>>> >>>>>component MyComponentSession : MyComponent supports >>>SessionComponent { >>>>>} ; >>>>> >>>>>Here are my 0.02 euros of the day >>>>> >>>>>Raphal >>>>> >>>>>-- >>>>> ___ Raphael MARVIE (marvie@lifl.fr) >>>http://www.lifl.fr/~marvie >>>>> /_ _\ Equipe GOAL - Labo. d'Informatique Fondamentale de >>>Lille >>>>> @ 0 0 @ UPRESA 8022 - Bat. M3 - 59655 Villeneuve d'Ascq >>>(France) >>>>>_o0o_O_o0o_ phone: +33 (0)3 20 43 47 21 - fax: +33 (0)3 20 43 65 >>>66 >>>> >>>> >>>>================================================================== >>>>Dr. Jon Siegel email: siegel@omg.org >>>>Director, Technology Transfer http://www.omg.org >>>>Object Management Group >>>>First Needham Place Phone: 781-444-0404 >>>>250 First Avenue, Suite 201 Fax: 781-444-0320 >>>>Needham, MA 02494 USA >>>>================================================================== >>> >>> >>>================================================================== >>>Dr. Jon Siegel email: siegel@omg.org >>>Director, Technology Transfer http://www.omg.org >>>Object Management Group >>>First Needham Place Phone: 781-444-0404 >>>250 First Avenue, Suite 201 Fax: 781-444-0320 >>>Needham, MA 02494 USA >>>================================================================== >> >>************************************************************** >>Ed Cobb, Vice President, Architecture & Standards >>BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >>Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 >>E-mail: ed.cobb@bea.com >>************************************************************** > >************************************************************** >Ed Cobb, Vice President, Architecture & Standards >BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 >E-mail: ed.cobb@bea.com >************************************************************** ================================================================== Dr. Jon Siegel email: siegel@omg.org Director, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: 781-444-0404 250 First Avenue, Suite 201 Fax: 781-444-0320 Needham, MA 02494 USA ================================================================== Date: Sat, 19 May 2001 12:14:08 +0200 From: 520065607613-0001@t-online.de (Frank Pilhofer) To: Jon Siegel Cc: Edward Cobb , components-ftf@omg.org, ccm@eurescom.de, issues@omg.org, Juergen Boldt Subject: Re: "supports" terminology issue for CCM Message-ID: <20010519121407.A535@rose.fpx.de> Reply-To: Frank Pilhofer References: <5.0.0.25.2.20010518094624.00a62eb0@santa-clara.beasys.com> <4.3.2.7.2.20010518151336.00bcf7b0@192.67.184.65> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010518151336.00bcf7b0@192.67.184.65>; from siegel@omg.org on Fri, May 18, 2001 at 03:18:26PM -0400 X-Sender: 520065607613-0001@t-dialin.net Content-Type: text/plain; charset=us-ascii X-UIDL: ;\?!!F2B!!)15e9B2Me9 Jon Siegel wrote: > > I'd like to make this a CCM issue, unless anyone objects. I don't > think OMG specifications should use a single term in two distinctly > different ways. The text of the issue starts with the sentence, > "the Components spec and valuetype spec treat "supports" exactly > **OPPOSITE** in semantics regarding widening/narrowing." and continues > for about 3 or 4 paragraphs. Ed's comment should go in there too. > I don't think this is too big a problem. Basically, "supports" expresses the same relationship on both components and value types. If a component or valuetype supports an interface, it means that they offer, as part of their interface, all attributes and methods of the supported interface. So supporting an interface is rather equivalent to inheriting that interface. We have a new key word for that since neither value types nor components can inherit a plain old interface. (Well, the true reason for that is likely the Java origin of value types, where you have classes (value types) that implement (support) an interface. IDL would have been free to attach reasonable semantics for value types inheriting interfaces.) Once you start from there, "inheriting an interface" results, pretty straightforwardly, in the relationships currently defined for value types and components. Frank -- Frank Pilhofer ........................................... fp@fpx.de A born executive is someone whose father owns the business. - Alfred E. Neuman X-Sender: siegel@192.67.184.65 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 07:47:19 -0400 To: Frank Pilhofer From: Jon Siegel Subject: Re: "supports" terminology issue for CCM Cc: Edward Cobb , components-ftf@omg.org, ccm@eurescom.de, Juergen Boldt In-Reply-To: <20010519121407.A535@rose.fpx.de> References: <4.3.2.7.2.20010518151336.00bcf7b0@192.67.184.65> <5.0.0.25.2.20010518094624.00a62eb0@santa-clara.beasys.com> <4.3.2.7.2.20010518151336.00bcf7b0@192.67.184.65> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: gE4e9TH#e9ec"e95aCe9 Hi again -- It's not too big a problem unless you think inheritance is important. I agree that the use of "supports" in CCM and valuetypes is functionally equivalent, but the semantics regarding inheritance are **opposite** in the two cases. I'm the author of the OMG definition and acronym list (www.omg.org/gettingstarted/groupterms_and_acronyms.htm) and hate to think what I'll have to write for "supports" if this doesn't get changed. We're writing standards, and they're supposed to be clear and unambiguous, and the use of "supports" as an IDL keyword that means two opposite things depending on where it's used does not meet this requirement. OK? Thanks! Jon S. At 12:14 PM 5/19/01 +0200, Frank Pilhofer wrote: >Jon Siegel wrote: >> >> I'd like to make this a CCM issue, unless anyone objects. I don't >> think OMG specifications should use a single term in two distinctly >> different ways. The text of the issue starts with the sentence, >> "the Components spec and valuetype spec treat "supports" exactly >> **OPPOSITE** in semantics regarding widening/narrowing." and continues >> for about 3 or 4 paragraphs. Ed's comment should go in there too. >> > > I don't think this is too big a problem. > > Basically, "supports" expresses the same relationship on both components >and value types. If a component or valuetype supports an interface, it >means that they offer, as part of their interface, all attributes and >methods of the supported interface. > > So supporting an interface is rather equivalent to inheriting that >interface. We have a new key word for that since neither value types >nor components can inherit a plain old interface. > > (Well, the true reason for that is likely the Java origin of value >types, where you have classes (value types) that implement (support) >an interface. IDL would have been free to attach reasonable semantics >for value types inheriting interfaces.) > > Once you start from there, "inheriting an interface" results, pretty >straightforwardly, in the relationships currently defined for value >types and components. > > Frank > > >-- >Frank Pilhofer ........................................... fp@fpx.de >A born executive is someone whose father owns the business. >- Alfred E. Neuman ================================================================== Dr. Jon Siegel email: siegel@omg.org Director, Technology Transfer http://www.omg.org Object Management Group First Needham Place Phone: 781-444-0404 250 First Avenue, Suite 201 Fax: 781-444-0320 Needham, MA 02494 USA ================================================================== Date: Thu, 4 Oct 2001 15:16:39 +0200 From: 520065607613-0001@t-online.de (Frank Pilhofer) To: Components FTF Subject: Re: Issue 4329: "supports" terminology issue for CCM Message-ID: <20011004151639.D436@rose.fpx.de> Reply-To: Frank Pilhofer Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Sender: 520065607613-0001@t-dialin.net Content-Type: text/plain; charset=us-ascii X-UIDL: glo!!5gp!!@$[d9V0ld9 Hi, I propose to close this issue with no change. It seems to be agreed that the issue is not a technical one, as the usage of "supports" for components is, in syntax and semantics, the same as for valuetypes: the component/valuetype will offer all operations and attributes from the supported interface. In both cases, "true" inheritance is not used because inheritance should only be used within the same type hierarchy. The difference with respect to widening is a side effect of using interface inheritance for supported interfaces in equivalent IDL, and this is not easy to avoid. I strongly oppose introducing a new keyword in the stead of "supports" here. Frank -- Frank Pilhofer ........................................... fp@fpx.de How is it that people looking for a helping hand tend to overlook the one at the end of their arm? - Alfred E. Neuman Date: Wed, 19 Sep 2001 11:06:21 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard SSO Staff, Florham Park NJ, USA X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank Pilhofer Cc: Components FTF Subject: Re: Issue 4329: "supports" terminology issue for CCM References: <20011004151639.D436@rose.fpx.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :c/e9E4hd9T-b!!lY9e9 Frank Pilhofer wrote: > > Hi, > > I propose to close this issue with no change. > > It seems to be agreed that the issue is not a technical one, as > the usage of "supports" for components is, in syntax and semantics, > the same as for valuetypes: the component/valuetype will offer all > operations and attributes from the supported interface. In both cases, > "true" inheritance is not used because inheritance should only be used > within the same type hierarchy. > > The difference with respect to widening is a side effect of using > interface inheritance for supported interfaces in equivalent IDL, > and this is not easy to avoid. I strongly oppose introducing a > new keyword in the stead of "supports" here. I agree. Jishnu. Date: Thu, 04 Oct 2001 17:37:50 +0200 From: Olaf Kath Reply-To: kath@ikv.de Organization: IKV++ Technologies AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: de,en MIME-Version: 1.0 To: Frank Pilhofer CC: Components FTF Subject: Re: Issue 4329: "supports" terminology issue for CCM References: <20011004151639.D436@rose.fpx.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: ;p?e9;Db!!*>^d90`Z!! Hi Frank, I fully aggree - and I also think, that this was the result of our longer discussion on the issue at the Berlin and Danvers workshops. Cheers, Olaf Frank Pilhofer wrote: Hi, I propose to close this issue with no change. It seems to be agreed that the issue is not a technical one, as the usage of "supports" for components is, in syntax and semantics, the same as for valuetypes: the component/valuetype will offer all operations and attributes from the supported interface. In both cases, "true" inheritance is not used because inheritance should only be used within the same type hierarchy. The difference with respect to widening is a side effect of using interface inheritance for supported interfaces in equivalent IDL, and this is not easy to avoid. I strongly oppose introducing a new keyword in the stead of "supports" here. Frank -- Olaf Kath IKV++ Technologies AG email kath@ikv.de http://www.ikv.de +49-(0)30-3480 770 X-Sender: evans@mail.cpi.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Oct 2001 11:53:59 -0400 To: components-ftf@omg.org From: "J. Scott Evans" Subject: Re: Issue 4329: "supports" terminology issue for CCM In-Reply-To: <20011004151639.D436@rose.fpx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: @Ei!!#"id9TK)e9~oV!! Hi, From a philosophical perspective there may still be issues but from an implementation perspective I would have to agree with you. Scott At 03:16 PM 10/4/01 +0200, you wrote: Hi, I propose to close this issue with no change. It seems to be agreed that the issue is not a technical one, as the usage of "supports" for components is, in syntax and semantics, the same as for valuetypes: the component/valuetype will offer all operations and attributes from the supported interface. In both cases, "true" inheritance is not used because inheritance should only be used within the same type hierarchy. The difference with respect to widening is a side effect of using interface inheritance for supported interfaces in equivalent IDL, and this is not easy to avoid. I strongly oppose introducing a new keyword in the stead of "supports" here. Frank -- Frank Pilhofer ........................................... fp@fpx.de How is it that people looking for a helping hand tend to overlook the one at the end of their arm? - Alfred E. Neuman