Issue 3859: The IDL contained in the PIDS specification is not CORBA compliant (pids-rtf2) Source: (, ) Nature: Revision Severity: Minor Summary: The IDL contained in the PIDS specification is not CORBA compliant. Specifically, the declarations struct TaggedProfile { PersonId id; Profile profile; }; and struct TraitSelector { Trait trait; float weight; }; fail to comply with the rule that the semantics of OMG IDL forbids identifiers in the same scope to differ only in case. The PIDS IDL will compile under the OrbixWeb ORB, but it fails to compile under ORBacus unless the --case-sensitive option (which is not CORBA compliant) is used. Resolution: see below Revised Text: Insert the prefix "PersonIdService::" into the appropriate contexts as shown here: struct TraitSelector { PersonIdService::Trait trait; struct TraitSelector { PersonIdService::Trait trait; float weight; }; typedef sequence<TraitSelector> TraitSelectorSeq; struct Candidate { PersonId id; float confidence; PersonIdService::Profile profile; }; .. struct TaggedProfile { PersonId id; PersonIdService::Profile profile; }; typedef sequence<TaggedProfile> TaggedProfileSeq; struct QualifiedTaggedProfile { QualifiedPersonId id; PersonIdService::Profile profile; }; Actions taken: September 15, 2000: received issue February 27, 2001: closed issue Discussion: Resolution: Prefix each of the offending types with the qualifier "PersonIdService::" as follows: struct TraitSelector { PersonIdService::Trait trait; End of Annotations:===== From: webmaster@omg.org Message-Id: <200009151525.e8FFPDR28161@emerald.omg.org> Date: 15 Sep 2000 11:27:33 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: \PF!!D6Le9hGh!!mKo!! Name: David Ellis Company: ESI Technology Corporation mailFrom: dellis@esitechnology.com Notification: Yes Specification: Person Identification Service Section: A.1 FormalNumber: formal/00-06-30 Version: 1.0 RevisionDate: June 2000 Page: A-2, A-3 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description The IDL contained in the PIDS specification is not CORBA compliant. Specifically, the declarations struct TaggedProfile { PersonId id; Profile profile; }; and struct TraitSelector { Trait trait; float weight; }; fail to comply with the rule that the semantics of OMG IDL forbids identifiers in the same scope to differ only in case. The PIDS IDL will compile under the OrbixWeb ORB, but it fails to compile under ORBacus unless the --case-sensitive option (which is not CORBA compliant) is used. Reply-To: "Jon Farmer" From: "Jon Farmer" To: "Andrew Watson" Cc: , , "Juergen Boldt" References: <4.2.0.58.20000928133426.00c71780@emerald.omg.org> Subject: Re: issue 3859 -- PIDS RTF issue Date: Thu, 28 Sep 2000 14:23:15 -0400 Organization: Care Data Systems MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 22!!!7='!!G'~e9i(Rd9 Andrew, Here is the issue I approached you about in Burlingame, the one you thought you might handle as an editorial issue. Jon ----- Original Message ----- From: Juergen Boldt To: ; Sent: Thursday, September 28, 2000 1:35 PM Subject: issue 3859 -- PIDS RTF issue > This is issue # 3859 (David Ellis, dellis@esitechnology.com ) > > The IDL contained in the PIDS specification is not CORBA compliant > > The IDL contained in the PIDS specification is not CORBA compliant. > > Specifically, the declarations > > struct TaggedProfile { PersonId id; Profile profile; }; > > and > > struct TraitSelector { Trait trait; float weight; }; > > fail to comply with the rule that the semantics of OMG IDL forbids > identifiers in the same scope to differ only in case. > > The PIDS IDL will compile under the OrbixWeb ORB, but it fails to >compile > under ORBacus unless the --case-sensitive option (which is not CORBA > compliant) is used. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ > Reply-To: "Jon Farmer" From: "Jon Farmer" To: "Andrew Watson" Cc: , , "Juergen Boldt" References: <4.2.0.58.20000928133426.00c71780@emerald.omg.org> Subject: Re: issue 3859 -- PIDS RTF issue Date: Fri, 29 Sep 2000 12:11:01 -0400 Organization: Care Data Systems MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,?k!!l?Y!!M>f!!-nVd9 OK ----- Original Message ----- From: Andrew Watson To: Jon Farmer Cc: ; ; Juergen Boldt Sent: Friday, September 29, 2000 11:41 AM Subject: Re: issue 3859 -- PIDS RTF issue > Jon, > > You wrote: > > > Here is the issue I approached you about in Burlingame, the one >you > > thought you might handle as an editorial issue. > > I could indeed declare it as editorial, and get Linda to fix it >during > editing. However, if there's an active RTF, it would be slightly >better for > you to resolve it using the RTF voting process, just to make sure >one of > the clashing operations gets renamed to something that makes sense >in PIDS. > > Thanks, > > Andrew > > > X-Sender: andrew@emerald.omg.org Message-Id: In-Reply-To: <007401c02979$30fb6fa0$181e85cd@toledolink.com> References: <4.2.0.58.20000928133426.00c71780@emerald.omg.org> Mime-Version: 1.0 Date: Fri, 29 Sep 2000 11:41:55 -0400 To: "Jon Farmer" From: Andrew Watson Subject: Re: issue 3859 -- PIDS RTF issue Cc: , , "Juergen Boldt" Content-Type: text/plain; charset="us-ascii" X-UIDL: H`L!!=pEe9BT?e98*~e9 Jon, You wrote: > Here is the issue I approached you about in Burlingame, the one you > thought you might handle as an editorial issue. I could indeed declare it as editorial, and get Linda to fix it during editing. However, if there's an active RTF, it would be slightly better for you to resolve it using the RTF voting process, just to make sure one of the clashing operations gets renamed to something that makes sense in PIDS. Thanks, Andrew Reply-To: "Jon Farmer" From: "Jon Farmer" To: References: <4.2.0.58.20000928133426.00c71780@emerald.omg.org> Subject: Re: issue 3859 -- PIDS RTF issue Date: Mon, 30 Oct 2000 10:05:31 -0500 Organization: Care Data Systems MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \#c!!E_Sd9HaMd9$Y!!! Hello folks, the PIDS RTF3 comment deadline has expired (October 9) and our Final Report is Due November 20. We only have two issues to discuss and resolve. I will very soon set up a conference call to resolve these, but first I'll start with some discussion on 3859: = 3859 ======= this one simply needs to fix constructs "Profile profile" and "Trait trait", whcih are not legal in 2.3. The "fix" to this is highty arbitrary (unless anyone can find an OMG precedent), but here is what we did, to get the discussion rolling. struct TaggedProfile { PersonId id; Profile __profile; }; typedef sequence TaggedProfileSeq; struct QualifiedTaggedProfile { QualifiedPersonId id; Profile __profile; }; typedef sequence QualifiedTaggedProfileSeq; struct ProfileUpdate { PersonId id; TraitNameSeq del_list; TraitSeq modify_list; }; typedef sequence< ProfileUpdate > ProfileUpdateSeq; struct MergeStruct { PersonId id; PersonId preferred_id; }; typedef sequence< MergeStruct > MergeStructSeq; struct TraitSelector { Trait __trait; float weight; }; typedef sequence TraitSelectorSeq; struct Candidate { PersonId id; float confidence; Profile __profile; }; ----- Original Message ----- From: Juergen Boldt To: ; Sent: Thursday, September 28, 2000 12:35 PM Subject: issue 3859 -- PIDS RTF issue > This is issue # 3859 (David Ellis, dellis@esitechnology.com ) > > The IDL contained in the PIDS specification is not CORBA compliant > > The IDL contained in the PIDS specification is not CORBA compliant. > > Specifically, the declarations > > struct TaggedProfile { PersonId id; Profile profile; }; > > and > > struct TraitSelector { Trait trait; float weight; }; > > fail to comply with the rule that the semantics of OMG IDL forbids > identifiers in the same scope to differ only in case. > > The PIDS IDL will compile under the OrbixWeb ORB, but it fails to >compile > under ORBacus unless the --case-sensitive option (which is not CORBA > compliant) is used. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ > X-Sender: u076663@cic-mail.lanl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 09:25:49 -0700 To: "Jon Farmer" , From: David Forslund Subject: Re: issue 3859 -- PIDS RTF issue In-Reply-To: <00a501c04282$d9cee310$af1e85cd@toledolink.com> References: <4.2.0.58.20000928133426.00c71780@emerald.omg.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_49852494==_.ALT" X-UIDL: ?GS!!JD@!!::~!!S-'e9 What we have done, which was recommended to us by others as a "generic" solution to illegal IDL of this type, is to add the PersonIdService:: string to the beginning of each of the offending types as indicated below. This is simple, elegant and not arbitrary. struct TraitSelector { PersonIdService::Trait trait; float weight; }; typedef sequence TraitSelectorSeq; struct Candidate { PersonId id; float confidence; PersonIdService::Profile profile; }; .. struct TaggedProfile { PersonId id; PersonIdService::Profile profile; }; typedef sequence TaggedProfileSeq; struct QualifiedTaggedProfile { QualifiedPersonId id; PersonIdService::Profile profile; }; At 10:05 AM 10/30/2000 -0500, Jon Farmer wrote: Hello folks, the PIDS RTF3 comment deadline has expired (October 9) and our Final Report is Due November 20. We only have two issues to discuss and resolve. I will very soon set up a conference call to resolve these, but first I'll start with some discussion on 3859: = 3859 ======= this one simply needs to fix constructs "Profile profile" and "Trait trait", whcih are not legal in 2.3. The "fix" to this is highty arbitrary (unless anyone can find an OMG precedent), but here is what we did, to get the discussion rolling. struct TaggedProfile { PersonId id; Profile __profile; }; typedef sequence TaggedProfileSeq; struct QualifiedTaggedProfile { QualifiedPersonId id; Profile __profile; }; typedef sequence QualifiedTaggedProfileSeq; struct ProfileUpdate { PersonId id; TraitNameSeq del_list; TraitSeq modify_list; }; typedef sequence< ProfileUpdate > ProfileUpdateSeq; struct MergeStruct { PersonId id; PersonId preferred_id; }; typedef sequence< MergeStruct > MergeStructSeq; struct TraitSelector { Trait __trait; float weight; }; typedef sequence TraitSelectorSeq; struct Candidate { PersonId id; float confidence; Profile __profile; }; ----- Original Message ----- From: Juergen Boldt To: ; Sent: Thursday, September 28, 2000 12:35 PM Subject: issue 3859 -- PIDS RTF issue > This is issue # 3859 (David Ellis, dellis@esitechnology.com ) > > The IDL contained in the PIDS specification is not CORBA compliant > > The IDL contained in the PIDS specification is not CORBA compliant. > > Specifically, the declarations > > struct TaggedProfile { PersonId id; Profile profile; }; > > and > > struct TraitSelector { Trait trait; float weight; }; > > fail to comply with the rule that the semantics of OMG IDL forbids > identifiers in the same scope to differ only in case. > > The PIDS IDL will compile under the OrbixWeb ORB, but it fails to >compile > under ORBacus unless the --case-sensitive option (which is not CORBA > compliant) is used. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ > David W. Forslund dwf@lanl.gov Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-665-1907 FAX: 505-665-4939 Reply-To: "Jon Farmer" From: "Jon Farmer" To: "pids-rtf2" Subject: PIDS RTF3 conference call and email poll Date: Tue, 7 Nov 2000 10:59:42 -0500 Organization: Care Data Systems MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: F11!!!RD!!-5m!![<7!! Hi Folks, This note is to schedule a conference call and to put our only two issues conveniently in front of you - all in one email! Please look over the issues and gather your thoughts for the conference call and the email poll. ******* conf call info ***** In the conference call we will establish our draft proposed resolutions to these two issues. Monday, November 13, 12:00 noon Eastern time, for 90 minutes. The call-in number is 1-203-748-8964. When you dial that number you will be prompted to enter the last 4 numbers (8964) again and then enter the passcode ID which is 24715. The first person to call won't hear anything until the next person calls in. **********email issues poll info *********: The email poll will begin when the conference call ends. the conference call info is: your email poll responses will be due (please respond to the whole list) 9am Nov 20 so I can prepare the final report the same day. We have only two issues to deal with (3859 and . I pulled their text into tail of this email for your convenience. In each case I put the issue description for 3859 under a double line (=========) and proposed fix under single line (---------) Issue 3859:============================================== the issue itself: > This is issue # 3859 (David Ellis, dellis@esitechnology.com ) > > The IDL contained in the PIDS specification is not CORBA compliant > > The IDL contained in the PIDS specification is not CORBA compliant. > > Specifically, the declarations > > struct TaggedProfile { PersonId id; Profile profile; }; > > and > > struct TraitSelector { Trait trait; float weight; }; > > fail to comply with the rule that the semantics of OMG IDL forbids > identifiers in the same scope to differ only in case. > > The PIDS IDL will compile under the OrbixWeb ORB, but it fails to compile > under ORBacus unless the --case-sensitive option (which is not CORBA > compliant) is used. > --------------------------------- Dave Forslunds proposed fix ------------------------ What we have done, which was recommended to us by others as a "generic" solution to illegal IDL of this type, is to add the PersonIdService:: string to the beginning of each of the offending types as indicated below. This is simple, elegant and not arbitrary. struct TraitSelector { PersonIdService::Trait trait; float weight; }; typedef sequence TraitSelectorSeq; struct Candidate { PersonId id; float confidence; PersonIdService::Profile profile; }; .. struct TaggedProfile { PersonId id; PersonIdService::Profile profile; }; typedef sequence TaggedProfileSeq; struct QualifiedTaggedProfile { QualifiedPersonId id; PersonIdService::Profile profile; }; At 10:05 AM 10/30/2000 -0500, Jon Farmer wrote: --------- my proposed fix (I like DWF's above fix etter) ------------------ The "fix" to this is highty arbitrary (unless anyone can find an OMG precedent), but here is what we did, to get the discussion rolling. struct TaggedProfile { PersonId id; Profile __profile; }; typedef sequence TaggedProfileSeq; struct QualifiedTaggedProfile { QualifiedPersonId id; Profile __profile; }; typedef sequence QualifiedTaggedProfileSeq; struct ProfileUpdate { PersonId id; TraitNameSeq del_list; TraitSeq modify_list; }; typedef sequence< ProfileUpdate > ProfileUpdateSeq; struct MergeStruct { PersonId id; PersonId preferred_id; }; typedef sequence< MergeStruct > MergeStructSeq; struct TraitSelector { Trait __trait; float weight; }; typedef sequence TraitSelectorSeq; struct Candidate { PersonId id; float confidence; Profile __profile; }; issue 3789 ============================= This is issue # 3789 (Jon Farmer" ) "RequiredTraits" exception issue he "RequiredTraits" exception returns a sequence of traits. But make_ids_permenant takes an ARRAY of input ids. So this exception if thrown won't provide any usefull information as to which id had the problem. Our implementation, rather than throwing the exception, just creates the ID in a temporary state. However, as we recently considered supporting the exception in conjunction with a probabilistic matching algorithm, we found the following ambiguity: The RequiredTraits exception inlcudes a list of required traits, but the spec doesn't clarify that this is the complete list of required traits - assuming that its the same set for any input profile - so that the client can figure out which IDs need for traits. The problem with that semantic is as follows. Some probabilisitc matching algorithms can only determine the adequacy of the incoming trait set by inspecting the VALUES of the trait types supplied. for example, if the incoming request tries to register two ids, one with first=John , Last=Smith, and the second with First=Mergetroid Last=Pepperdyne, a probabilisitc algorithm will likely accept the second but reject the first; YET BOTH supplied the same traits. Hwo could the client figure out what's missing? How the server even figure out what's missing? Neither can. ONLY THE ALGORITHM KNOWS....... AND IT ONLY KNOWS ONCE IT HAS SEEN THE INPUTS. Therefore we need to define clearly what the exception semantics are, and in a way that doesn't preclude the use of probabilistic matchers that cannot assess adequacy in a "one trait list fits all" manner. ------------------------------- solution A ----------------------------- One possible solution is to have the exception return a SEQUENCE OF offending ids - so the client can know which are offensive. Instead of also including for each the set of traits needed, the return structure could show the confidence deficit for each. this fix would constitute an IDL change, justified by a classification of the issue as an IDL error - that is, the IDL doesn;t square with the semantics of a probabilistic implementation. ---------------------------------- solution B ----------------------------- A weasly but somewhat effective solution would be to simply return the list of "required traits", understanding tht a fgvien impelmentation, if it uses a probabilistic implementation - may not have any "required traits!" - however, if the implementation qualifies profiles BEFORE matching based on an extremely bare minimum set of mandatory trait types, then it could return these.