Issue 3451: MultipleExceptions (biomolecular-ftf) Source: Japan Biological Informatics Consortium (Mr. Martin Senger, martin.senger@gmail.com) Nature: Uncategorized Issue Severity: Summary: Doing my implementation of AnalysisService::create_analysis() I have found that MultipleExceptions exception does give me only little space for sending back explanation why the parameter checking failed. I can say what property caused the failure and I can roughly tell a type of this failure. But unfortunately there is no 'reason' string to be filled with an explanatory message. Resolution: closed Revised Text: Rejected. This was a contentious issue. One implementer requested the change, the other was satisfied with the existing specification. The issue was resolved by a vote with 1 YES, 2 NO, and 3 ABSTAIN. Actions taken: March 23, 2000: received issue May 24, 2001: closed issue Discussion: End of Annotations:===== Date: Thu, 23 Mar 2000 18:00:56 +0000 (GMT) From: Martin Senger To: biomolecular-ftf@omg.org Subject: MultipleExceptions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !$6!!,8jd9o^'!!gK"!! Dear FTFers, Doing my implementation of AnalysisService::create_analysis() I have found that MultipleExceptions exception does give me only little space for sending back explanation why the parameter checking failed. I can say what property caused the failure and I can roughly tell a type of this failure. But unfortunately there is no 'reason' string to be filled with an explanatory message. Can we discussed it a bit here please? Would it make sense to have an extended MultipleExceptions in our spec? The problem is that exceptions do not inherit so I cannot easily add my own extension. Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Sun, 18 Jun 2000 19:42:04 +0100 (BST) From: Martin Senger To: "Dickson, Mike" cc: "Markel, Scott" , BSA FTF Subject: issue 3451 - MultipleExceptions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c,i!!^hj!!Okp!!PgOe9 Dear Mike and the others, I am still not sure that we understand each other. Because I see this issue as a really "an omission", or even simpler "an error" in our spec, while Mike seems to be in favor of the current state. For me it means that either I am overlooking something , or we are still talking about two different issues. That's why I am bothering you again with my arguments (trying also to include answers to Mike's last mail). Also, as promised, I am proposing concrete solutions how to fix it (if we agree that there is something to be fixed). I am talking about MultipleExceptions used here: AnalysisInstance create_analysis (in CosPropertyService::Properties input) raises (CosPropertyService::MultipleExceptions); This method is used to send inputs to an analysis. Each input is defined by metadata (mandatory attributes are name, type and mandatorness). If there is anything wrong with one or more inputs, the MultipleExceptions is thrown. The reasons of the exception can be expressed as one of the following (together with the name of the property who caused the exception): enum ExceptionReason { invalid_property_name, conflicting_property, property_not_found, unsupported_type_code, unsupported_property, unsupported_mode, fixed_property, read_only_property }; The problem I see is that the reasons do not cover the whole space of possible exceptions. The second problem (which is "only" a design problem and standing alone would not do any harm) is that many of the listed reasons are not useful for our purposes. "property_not_found" is a very good and useable reason; "conflicting_property" is also a good reason, however, I would prefer to have an aditional explanation what exactly is in conflict; "unsupported_type_code" may be probably used for situation that a metadata for an input dictates one type but the client sends the input in a different type - again reasonable reason; However, I do not see usage for other reasons (I think that they were designed for cases where a set of properties is created or updated by clients, which is not out case, we are using only pre-defined properties names only with different values). On the other side, I need to send back to the clients somehow messages of the type (these are only examples): - the input value is out of the allowed range, - the data defined in the input value are not accessible (it may happen when the input is actually another object) because of this or that reason, - the client did not send some mandatory inputs, Mike said: > > Ideally the metadata should be driving how a client formulates > parameter sets. > My understanding is that metadata drive how a client formulates parameter sets but the metadata are not powerful enough to formulate the values of the parameters. Without extending your metadata you cannot specify proper ranges and many other things. But even if you could do that, the metadata are still a cookbook how the parameter sets can be prepared but any client can simply ignores it and sends to your server wrong parameters sets. And I am claiming now, very seriously, that out spec is not robust enough to deal with such situation. Mike said: > > In general though I found the MultipleExceptions model in the > PropertyService to be quite adequate here... > In this place I plead: could you explain me how your implementation can live without better exception handling? I do not want to know any compnay implementation details but simple an example how the bsa spes could be used. My proposal how to fix the problems I see: - gives possibility to send a simple untyped message as a reason for an exception, - but also gives opportunity to send typed exception - the same as with ExceptionReason but with different set of reasons. And I have no objections to add other "reasons" or to remove "reasons" from my proposal. I also do not mind if we use different names - at the moment I kept it close to the names used in CosPropertyService - to be easier to discuss about it. enum ExceptionType { conflicting_property, property_not_found, unsupported_type_code, property_is_mandatory, property_is_not_repeatable, property_value_not_accessible, property_value_out_of_range, unsupported_property_value }; struct PropertyException { string reason; ExceptionType type; CosPropertyService::PropertyName failing_property_name; }; typedef sequence PropertyExceptions; exception MultipleExceptions { PropertyExceptions exceptions; }; Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 19 Sep 2000 20:15:49 +0100 (BST) From: Martin Senger To: biomolecular-ftf@omg.org Subject: issue 3451 - a proposed resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2o'e97Jc!!2($!!+>1!! I was asked to make clear what solution is proposed for solving problem with the multiple exceptions. This is just a re-make of one of my previous mails to this list. Argumentation: -------------- I am talking about MultipleExceptions used here: AnalysisInstance create_analysis (in CosPropertyService::Properties input) raises (CosPropertyService::MultipleExceptions); This method is used to send inputs to an analysis. Each input is defined by metadata (mandatory attributes are name, type and mandatorness). If there is anything wrong with one or more inputs, the MultipleExceptions is thrown. The reasons of the exception can be expressed as one of the following (together with the name of the property who caused the exception): enum ExceptionReason { invalid_property_name, conflicting_property, property_not_found, unsupported_type_code, unsupported_property, unsupported_mode, fixed_property, read_only_property }; The problem I see is that the reasons do not cover the whole space of possible exceptions. The second problem (which is "only" a design problem and standing alone would not do any harm) is that many of the listed reasons are not useful for our purposes. "property_not_found" is a very good and useable reason; "conflicting_property" is also a good reason, however, I would prefer to have an aditional explanation what exactly is in conflict; "unsupported_type_code" may be probably used for situation that a metadata for an input dictates one type but the client sends the input in a different type - again reasonable reason; However, I do not see usage for other reasons (I think that they were designed for cases where a set of properties is created or updated by clients, which is not out case, we are using only pre-defined properties names only with different values). On the other side, I need to send back to the clients somehow messages of the type (these are only examples): - the input value is out of the allowed range, - the data defined in the input value are not accessible (it may happen when the input is actually another object) because of this or that reason, - the client did not send some mandatory inputs, Our proposal how to fix the problems - gives possibility to send a simple untyped message as a reason for an exception, - but also gives opportunity to send typed exception - the same as with ExceptionReason but with different set of reasons. Proposed resolution: -------------------- 1) To change (in DsLSRAnalysis module) raising CosPropertyService::MultipleExceptions (which occurs in two places) to raising MultipleExceptions. 2) To add to DsLSRAnalysis module the following: enum ExceptionType { conflicting_property, property_not_found, unsupported_type_code, property_is_mandatory, property_is_not_repeatable, property_value_not_accessible, property_value_out_of_range, unsupported_property_value }; struct PropertyException { string reason; ExceptionType type; CosPropertyService::PropertyName failing_property_name; }; typedef sequence PropertyExceptions; exception MultipleExceptions { PropertyExceptions exceptions; }; 3) To add explanatory text to the document (I will suggest or help with the text only after we agree on this issue, otherwise it would be waste of time :-)). --- end of the proposal --- Regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 19 Sep 2000 16:14:47 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m_k!!f^md9!D8!!>KFe9 Martin, We're probably fine with this, but we would also like to consider removing the dependence of the analysis module on the Property Service. One of the things we liked about using MultipleExceptions was that we were clearly leveraging that service. Now it's not so clear that we are/should. When you propose text for this, you might want to just copy most of the text you'll need straight from the Property Service. Scott Martin Senger wrote: > > I was asked to make clear what solution is proposed for solving problem > with the multiple exceptions. This is just a re-make of one of my previous > mails to this list. > > Argumentation: > -------------- > I am talking about MultipleExceptions used here: > > AnalysisInstance create_analysis (in CosPropertyService::Properties input) > raises (CosPropertyService::MultipleExceptions); > > This method is used to send inputs to an analysis. Each input is > defined by metadata (mandatory attributes are name, type and > mandatorness). If there is anything wrong with one or more inputs, the > MultipleExceptions is thrown. The reasons of the exception can be > expressed as one of the following (together with the name of the property > who caused the exception): > > enum ExceptionReason { > invalid_property_name, > conflicting_property, > property_not_found, > unsupported_type_code, > unsupported_property, > unsupported_mode, > fixed_property, > read_only_property > }; > > The problem I see is that the reasons do not cover the whole space of > possible exceptions. The second problem (which is "only" a design problem > and standing alone would not do any harm) is that many of the listed > reasons are not useful for our purposes. > "property_not_found" is a very good and useable reason; > "conflicting_property" is also a good reason, however, I would prefer > to have an aditional explanation what exactly is in conflict; > "unsupported_type_code" may be probably used for situation that a > metadata for an input dictates one type but the client sends the input in > a different type - again reasonable reason; > However, I do not see usage for other reasons (I think that they were > designed for cases where a set of properties is created or updated by > clients, which is not out case, we are using only pre-defined properties > names only with different values). > > On the other side, I need to send back to the clients somehow messages > of the type (these are only examples): > - the input value is out of the allowed range, > - the data defined in the input value are not accessible (it may happen > when the input is actually another object) because of this or that reason, > - the client did not send some mandatory inputs, > > Our proposal how to fix the problems > - gives possibility to send a simple untyped message as a reason for an > exception, > - but also gives opportunity to send typed exception - the same as with > ExceptionReason but with different set of reasons. > > Proposed resolution: > -------------------- > 1) To change (in DsLSRAnalysis module) raising > CosPropertyService::MultipleExceptions (which occurs in two places) to > raising MultipleExceptions. > > 2) To add to DsLSRAnalysis module the following: > > enum ExceptionType { > conflicting_property, > property_not_found, > unsupported_type_code, > property_is_mandatory, > property_is_not_repeatable, > property_value_not_accessible, > property_value_out_of_range, > unsupported_property_value > }; > > struct PropertyException { > string reason; > ExceptionType type; > CosPropertyService::PropertyName failing_property_name; > }; > > typedef sequence PropertyExceptions; > > exception MultipleExceptions { > PropertyExceptions exceptions; > }; > > 3) To add explanatory text to the document (I will suggest or help with > the text only after we agree on this issue, otherwise it would be waste of > time :-)). > > --- end of the proposal --- > > Regards, > Martin > > -- > Martin Senger > > EMBL Outstation - Hinxton Senger@EBI.ac.uk > European Bioinformatics Institute Phone: (+44) 1223 494636 > Wellcome Trust Genome Campus (Switchboard: 494444) > Hinxton Fax : (+44) 1223 494468 > Cambridge CB10 1SD > United Kingdom http://industry.ebi.ac.uk/~senger -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 20 Sep 2000 00:44:57 +0100 (BST) From: Martin Senger To: Scott Markel cc: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution In-Reply-To: <39C7F367.7B98B641@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9p,e9kSSd9SM8!!=X,!! > > ...but we would also like to consider > removing the dependence of the analysis module on the Property > Service. > I am affraid that it would be almost unpossible because we are using Properties as a basic type for sending inputs to the analysis, and returning results back. That would be quite major change. I am not > sure that I understood you correctly... > > When you propose text for this, you might want to just copy most of > the > text you'll need straight from the Property Service. > I will work on the text tomorrow (my time). Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 19 Sep 2000 16:52:19 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ae$"!Z$;e92m&!!(\P!! Martin, Martin Senger wrote: > > > > > ...but we would also like to consider > > removing the dependence of the analysis module on the Property Service. > > > I am affraid that it would be almost unpossible because we are using > Properties as a basic type for sending inputs to the analysis, and > returning results back. That would be quite major change. I am not sure > that I understood you correctly... I'm suggesting that we could also define our own name/value (string/any) pairs. Scott -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 20 Sep 2000 00:54:46 +0100 (BST) From: Martin Senger To: Scott Markel cc: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution In-Reply-To: <39C7FC33.7F9EB3F6@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 21p!!PO!!!ja+e9dRJe9 > > I'm suggesting that we could also define our own name/value > (string/any) > pairs. > Okay, so I understood you well :-) Do you have any special reasons to do it? To be fair, at the moment > I am scared by such suggestion. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Dion: 1.0 To: Martin Senger CC: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: '"gd9Xa'e9$kMe9^"Ee9 Martin, Martin Senger wrote: > > > I'm suggesting that we could also define our own name/value (string/any) > > pairs. > > > Okay, so I understood you well :-) > Do you have any special reasons to do it? If we're going to mimic functionality from the Property Service within the DsLSRAnalysis module, making changes we think are appropriate, then, in addition to MultipleExceptions, I think we should also explore doing the same for Properties. The obvious example is to make a Property, the container for the name/value pair, a valuetype so that it can be extended. valuetype Property { public string name; public any value; }; typedef sequence Properties; > To be fair, at the moment I > am scared by such suggestion. I'm not sure I understand this. Scott -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Mon, 25 Sep 2000 22:32:32 +0100 (BST) From: Martin Senger To: Scott Markel cc: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution In-Reply-To: <39CFC138.A48CD8D9@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \N$!!,T:e9<\gd9C\ed9 Scott, > > If we're going to mimic functionality from the Property Service > within > the DsLSRAnalysis module, > I am not suggesting to mimic functionality from the Property > Service. It is upside-down: what we have now in our spec is trying to mimic the Property Service (talking about MultipleExceptions) but - in my > opinion - unsatisfactorily. The functionality of MultipleExceptions is simply > not sufficient for the needs of the BSA spec (this is not an opinion, this > is the fact :-)). Therefore, I am suggesting to replace > MultipleExceptions with something better. > > in addition to MultipleExceptions, I think we should also explore >doing > the same for Properties. > Generally speaking, I would not be against such suggestion (and we >went through such proposal several times - remember Millenium's Envelopes >of EBI's NameValue pairs (or what was the name of it). But, regarding the state of out BSA implementation I am not in >favour to make such change. We would have to re-code too much. Fortunately, those who want to extend Properties from Property >Service, can do it by putting their own data types in Any. > > > To be fair, at the moment I > > am scared by such suggestion. > > I'm not sure I understand this. > Just that I am not prepared to do big changes unless they are really neccessary. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 26 Sep 2000 13:57:08 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: + > Scott, > > > If we're going to mimic functionality from the Property Service within > > the DsLSRAnalysis module, > > > I am not suggesting to mimic functionality from the Property Service. > It is upside-down: what we have now in our spec is trying to mimic the > Property Service (talking about MultipleExceptions) but - in my opinion - > unsatisfactorily. The functionality of MultipleExceptions is simply not > sufficient for the needs of the BSA spec (this is not an opinion, this is > the fact :-)). Therefore, I am suggesting to replace MultipleExceptions > with something better. I should have been clearer when I used mimic. What I meant was that you're proposing to largely reproduce the functionality of MultipleExceptions. The only changes I noticed are the changes to the enum and the addition of a reason string to PropertyException. The use of an enum, a struct for the single exception (i.e., not changing it to a valuetype), and the wrapper for a sequence of structs (the exceptions) all faithfully reproduce the patterns in the PropertyService. What we have now does not mimic MultipleExceptions. It uses it directly. Note, by the way, that, when I say "only", I don't mean to minimize the usefulness of the new enum elements. > > in addition to MultipleExceptions, I think we should also explore doing > > the same for Properties. > > > Generally speaking, I would not be against such suggestion (and we went > through such proposal several times - remember Millenium's Envelopes of > EBI's NameValue pairs (or what was the name of it). > But, regarding the state of out BSA implementation I am not in favour > to make such change. We would have to re-code too much. > Fortunately, those who want to extend Properties from Property Service, > can do it by putting their own data types in Any. > > > > To be fair, at the moment I > > > am scared by such suggestion. > > > > I'm not sure I understand this. > > > Just that I am not prepared to do big changes unless they are really > neccessary. I don't see it as a very big change - certainly no more than the one involving MultipleExceptions. In Java the coding change forced by moving the IDL location of Properties is just a package name change, nothing more. Scott -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 From: "Dickson, Mike" To: "Markel, Scott" , Martin Senger Cc: biomolecular-ftf@omg.org Subject: RE: issue 3451 - a proposed resolution Date: Tue, 26 Sep 2000 17:54:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b~Ge9@I2e9pMpd9*g@!! Just one additional point. If we change the semantics of MultipleExceptions we are in fact only using a struct from the PropertyService and are in fact not emulating any of the semantics of the service at all. I can't simply delegate property oriented behaviour to an existing property service. That being the case I'd assert that continuing to use definitions from the PropertyService is both confusing and misleading. OTOH, I didn't see the Property semantics from the property service as incomplete (and frankly still don't) for our purpose which is why I originally proposed that approach. So in short, my belief is that if we change the semantics of MultipleExceptions we should do the right thing and remove the dependancy on the OMG PropertyService. BTW, either (or both) change(s) requires modifications to code we've developed. That to me is an insufficient reason to dictate wether we make these proposed changes. Mike > -----Original Message----- > From: Scott Markel [mailto:smarkel@netgenics.com] > Sent: Tuesday, September 26, 2000 4:57 PM > To: Martin Senger > Cc: biomolecular-ftf@omg.org > Subject: Re: issue 3451 - a proposed resolution > > > Martin, > > Martin Senger wrote: > > > > Scott, > > > > > If we're going to mimic functionality from the Property > Service within > > > the DsLSRAnalysis module, > > > > > I am not suggesting to mimic functionality from the > Property Service. > > It is upside-down: what we have now in our spec is trying > to mimic the > > Property Service (talking about MultipleExceptions) but - > in my opinion - > > unsatisfactorily. The functionality of MultipleExceptions > is simply not > > sufficient for the needs of the BSA spec (this is not an > opinion, this is > > the fact :-)). Therefore, I am suggesting to replace > MultipleExceptions > > with something better. > > I should have been clearer when I used mimic. What I meant was that > you're proposing to largely reproduce the functionality of > MultipleExceptions. The only changes I noticed are the changes to the > enum and the addition of a reason string to > PropertyException. The use > of an enum, a struct for the single exception (i.e., not > changing it to > a valuetype), and the wrapper for a sequence of structs (the > exceptions) > all faithfully reproduce the patterns in the PropertyService. What we > have now does not mimic MultipleExceptions. It uses it directly. > > Note, by the way, that, when I say "only", I don't mean to > minimize the > usefulness of the new enum elements. > > > > in addition to MultipleExceptions, I think we should also > explore doing > > > the same for Properties. > > > > > Generally speaking, I would not be against such > suggestion (and we went > > through such proposal several times - remember Millenium's > Envelopes of > > EBI's NameValue pairs (or what was the name of it). > > But, regarding the state of out BSA implementation I am > not in favour > > to make such change. We would have to re-code too much. > > Fortunately, those who want to extend Properties from > Property Service, > > can do it by putting their own data types in Any. > > > > > > To be fair, at the moment I > > > > am scared by such suggestion. > > > > > > I'm not sure I understand this. > > > > > Just that I am not prepared to do big changes unless > they are really > > neccessary. > > I don't see it as a very big change - certainly no more than the one > involving MultipleExceptions. In Java the coding change > forced by moving > the IDL location of Properties is just a package name change, nothing > more. > > Scott > > -- > Scott Markel, Ph.D. NetGenics, Inc. > smarkel@netgenics.com 4350 Executive Drive > Tel: 858 455 5223 Suite 260 > FAX: 858 455 1388 San Diego, CA 92121 > Date: Wed, 27 Sep 2000 01:20:30 +0100 (BST) From: Martin Senger To: "Dickson, Mike" cc: "Markel, Scott" , biomolecular-ftf@omg.org Subject: RE: issue 3451 - a proposed resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~'dd9g53!!0"?e9I1,!! Mike, your English is too complicated to me. I do not understand why MultipleExceptions must be solved together with removing Property Service completely. I also start to loose my patience. I said several times that using MultipleExceptions from Property Service makes BSA spec almost unsuable. I asked you if you can show me how you can inform clients what's wrong with input parameters by using only MultipleExceptions. You did not answer. I still feel what I just said about useability. I can be even stronger: if the BSA spec remains like it is now I simply do not know how to implement it - and I will be asking to put this opinion into the final report. Having or not having Properties from Property Service is an independent issue. Make your proposal how you suggest to change it. I am not sure now what will be our point of view on that. Martin Scot, > > > > I don't see it as a very big change - certainly no more than the > > one > > involving MultipleExceptions. > But changes involving MultipleExceptions are necessary, changes > > with Properties are just a question of style. For changing ME I _have_ to > > do whatever changes needed because what we together put into BSA spec is simple wrong. Period. > > In Java the coding change > > forced by moving > > the IDL location of Properties is just a package name change, >nothing > > more. No, I disagree. Changing struct to valuetypes involves more. But >that's not the main point. I said above that I will consider your proposal >when you make it. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 24 Oct 2000 15:29:28 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: "Dickson, Mike" , biomolecular-ftf@omg.org Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6Aod9lo~e9YT!!!HX2!! Martin, We still think that BSA's use of MultipleExceptions is coupled with use of Properties and the semantics of the PropertyService. We believe that if one of the parts (MultipleExceptions) is dropped/replaced, then the entire approach should be rethought. We'll vote no on this issue. Scott Martin Senger wrote: > > Mike, > your English is too complicated to me. I do not understand why > MultipleExceptions must be solved together with removing Property Service > completely. > I also start to loose my patience. I said several times that using > MultipleExceptions from Property Service makes BSA spec almost unsuable. I > asked you if you can show me how you can inform clients what's wrong with > input parameters by using only MultipleExceptions. You did not answer. > I still feel what I just said about useability. I can be even stronger: > if the BSA spec remains like it is now I simply do not know how to > implement it - and I will be asking to put this opinion into the final > report. > > Having or not having Properties from Property Service is an independent > issue. Make your proposal how you suggest to change it. I am not sure now > what will be our point of view on that. > > Martin > > Scot, > > > > > > > I don't see it as a very big change - certainly no more than the one > > > involving MultipleExceptions. > > > But changes involving MultipleExceptions are necessary, changes with > Properties are just a question of style. For changing ME I _have_ to do > whatever changes needed because what we together put into BSA spec is > simple wrong. Period. > > > > > In Java the coding change > > > forced by moving > > > the IDL location of Properties is just a package name change, nothing > > > more. > No, I disagree. Changing struct to valuetypes involves more. But that's > not the main point. I said above that I will consider your proposal when > you make it. > > Martin -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 25 Oct 2000 00:45:20 +0100 (BST) From: Martin Senger To: Scott Markel cc: "Dickson, Mike" , biomolecular-ftf@omg.org, Alan Robinson Subject: Re: issue 3451 - a proposed resolution In-Reply-To: <39F60D48.288BF0D4@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: R:Wd9G=D!!3:=!!Ka~!! Attention, please, THIS IS SERIOUS!. > > We still think that BSA's use of MultipleExceptions is coupled with > use > of Properties and the semantics of the PropertyService. We believe > that > if one of the parts (MultipleExceptions) is dropped/replaced, then > the > entire approach should be rethought. > I am not going to repeat here my arguments (please ask me if you > lost my previous mail about it). I am just going to try to convince you BY > ALL MEANS that the current MultipleExceptions make the specification > almost useless in one of its major goals - "to start and run an analysis"! The NetGenics repeateadly answers that "they do nor believe". But > they did not come with any concrete arguments. The fact that THEIR implementation does not suffer from having the MultipleException as > they exist now is suprising but possible, but I am fully convinced that > other implementations (and believe me I am not talking just about ours) > would be harmed if an exception why the input values are wrong cannot be > expressed as a string. Also there is a surprising fact that NetGenics could accept a new MultipleException IF the PropertyService is dropped out entirely. But > they did not come with any proposal to do it. I have said that these two > topics are independent - which may not reflect their opinion but still we > have no proposal how to drop entire PropertyService! I feel very strongly > about MultipleException, so strongly that I may accept new properties - even > if I do not understand the relationship between them and ME. This topic is very different from (most of) all other issues. It shows that something very important simply cannot be done with the BSA spec. And having one single string added can cure it - believe me I made my proposal with all fancy "enums" just to pleased object-oriented minds in Netgenics, I would be happy just with a stringified reason. So, please, all FTF members, tell us your opinions. Also, the timing is unfair. I have made the proposal in July - and we are going to vote on it six days before deadline. That's a shame. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 24 Oct 2000 17:11:36 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: "Dickson, Mike" , biomolecular-ftf@omg.org, Alan Robinson Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !n>e9&e#e9iR3e9B1*!! Martin, It's clear that we disagree on this issue. Both EBI and NetGenics have made technical arguments to support their respective positions. [Martin and I will be happy to point you to previous email messages.] The vote on EBI's proposal will be held this week. Let's move on. Scott PS > Also, the timing is unfair. I have made the proposal in July - and we > are going to vote on it six days before deadline. That's a shame. I agree. I had hoped that there would be additional discussion and that we would be able to achieve consensus on this issue. I should have included this issue in an earlier vote after it became clear that that wasn't going to happen. PPS By the time voting is done this week, I expect that we'll have had unanimous votes on 52 of 55 issues. I think we've done pretty well overall. -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 25 Oct 2000 01:23:47 +0100 (BST) From: Martin Senger To: Scott Markel cc: "Dickson, Mike" , biomolecular-ftf@omg.org, Alan Robinson Subject: Re: issue 3451 - a proposed resolution In-Reply-To: <39F62538.B447CD90@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: MU\d9Ub5e92fLe9Q]Sd9 > > > Scott, do not try to oversimplify things - my mail was not an "outburst" - I have weighted every word. > > Both EBI and NetGenics have > made technical arguments to support their respective positions. >[Martin > and I will be happy to point you to previous email messages.] > Please point ME in the first place to any mail where NetGenics made technical arguments against having a new ME. Because I do not recall >any technical argumementation. I am still trying to make other FTF members aware of the fact that the current MultipleException cannot return a reason why the input values are invalid IN ALL (if not most) CASES. Only very limited number of reasons can be returned now.This is simply an ommission in the BSA spec, not a plea for adding new functionality. This is very serious issue which we should make aware of the AB before considering their final approval on the spec, unless we cure it within this FTF. > > Also, the timing is unfair. I have made the proposal in July - and we > > are going to vote on it six days before deadline. That's a shame. > > I agree. I had hoped that there would be additional discussion and that > we would be able to achieve consensus on this issue. I should have > included this issue in an earlier vote after it became clear that that > wasn't going to happen. > But you did not - so now you should be looking for other solutions. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Tue, 24 Oct 2000 18:03:52 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: "Dickson, Mike" , biomolecular-ftf@omg.org, Alan Robinson Subject: Re: issue 3451 - a proposed resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &8[!!j:B!!K5'!!NX&e9 Martin, Martin Senger wrote: > > Both EBI and NetGenics have > > made technical arguments to support their respective positions. > > [Martin > > and I will be happy to point you to previous email messages.] > > > Please point ME in the first place to any mail where NetGenics > > made > technical arguments against having a new ME. Because I do not recall > > any > technical argumementation. See the initial exchange started by Mike in June after the Oslo meeting ("[BSA-FTF] Oslo minutes - Monday"). See also my message on 25 September where I outlined a valuetype-based approach to Properties ("issue 3451 - a proposed resolution"). Mike and I followed up with messages the next day. Scott -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 25 Oct 2000 02:23:39 +0100 (BST) From: Martin Senger To: Scott Markel cc: "Dickson, Mike" , biomolecular-ftf@omg.org, Alan Robinson Subject: Re: issue 3451 - a proposed resolution In-Reply-To: <39F63178.15D3C868@netgenics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )1^!!)Od!!9_o!!I<7!! > > > > > Please point ME in the first place to any mail where NetGenics made > > technical arguments against having a new ME. Because I do not recall any > > technical argumementation. > > See the initial exchange started by Mike in June after the Oslo meeting > ("[BSA-FTF] Oslo minutes - Monday"). > > See also my message on 25 September where I outlined a valuetype-based > approach to Properties ("issue 3451 - a proposed resolution"). Mike and > I followed up with messages the next day. > In those mails, you argued that substituting current MultipleExceptions would make existence of other usages of PropertyService weak. You did not bring any arguments why having a stringified reason is bad, at least not any technical arguments, except general arguments "we believe that it is not needed". I asked you how you could inform a client about invalid values such as "value is out of range", "value is mandatory", or "this value is in conflict with that value". I did not get any answer to these examples. So I still claim what I claimed before: I do not know about any technical reasons why we should not have a MultipleException containing a stringified reasons for its single sub-exceptions. And I repeat: my proposal can be changed, I do not insist on any particular list of "enum" values, feel free to change it as you prefer to suit your implementation. My only concern is to have there a stringified reason. Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger Date: Wed, 25 Oct 2000 19:10:13 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Senger CC: John_W_Quillen@sbphrd.com, Karl Konnerth , "Douglas S.Greer" , Jeroen Coppieters , mpetrin@concept5.com, "Dickson, Mike" , W_David_Benton@sbphrd.com, Alan Robinson , Philip Lijnzaad , BSA FTF Subject: Re: MultipleExceptions - a summary References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c`D!!d6Ie9f3De9'Xn!! I debated during the day whether or not to respond to Martin's message from last night regarding issue #3451 on MultipleExceptions. Since the distribution list for Martin's message was not the BSA FTF mailing list, I finally decided it was important to repeat the NetGenics position on this issue. NetGenics encouraged the use of the Property Service during the revised submission process. We believe that it's important to leverage existing OMG technologies. The use of Properties and MultipleExceptions solved problems in the analysis module. We still believe that this approach works. We've implemented the module and found no need to change BSA's use of these. Based on implementation experience EBI is proposing a change. They would like to a) enumerate all known exception reasons, or b) add a string to express a reason in a non-structured way, or c) combine a) and b) Please see Martin's message for details on EBI's proposal and view of the issue. The Property Service's MultipleExceptions exception contains a sequence of PropertyExceptions. PropertyException is a struct and cannot be extended. It, in turn, contains a reason. This data member contains one of eight enumerated ExceptionReasons. Enums also cannot be extended. All three of the changes EBI is proposing involve no longer using MultipleExceptions as defined in the Property Service. Moving away from the current specified use of the Property Service is problematic in a number of ways. First, it breaks the coupling of the use of the Property Service and the semantics defined there. If we define a BSA MultipleExceptions in order to provide a different set of enumerated ExceptionReasons, why should we continue to use Properties as defined in the Property Service? The combination of name (string) and value (any) is easy to reproduce within the BSA analysis module. Second, the introduction of a reason string with no attached semantics does nothing to aid in interoperability. For example, how are internationalization issues to be addressed? Should the string be a wstring? Should there be a controlled vocabulary? In summary, NetGenics has implemented the analysis module and sees no need for the change EBI is proposing. In addition, the proposed change will cause problems of its own. We're opposed to the proposed change for both reasons. In closing let me remind folks that BSA vote #5 is underway. The voting deadline for BSA FTF members is 5:00 PDT on Friday, 27 October. Issue #3451 is the first issue on the list for vote #5. The proposed resolution for this issue is the one EBI outlined originally and which Martin reiterated in his message last night. Scott PS Apologies to those who get multiple copies, but I want to keep the BSA FTF mailing list archive as complete as possible. -- Scott Markel, Ph.D. NetGenics, Inc. smarkel@netgenics.com 4350 Executive Drive Tel: 858 455 5223 Suite 260 FAX: 858 455 1388 San Diego, CA 92121 Date: Wed, 25 Oct 2000 19:12:44 -0700 From: Scott Markel Organization: NetGenics, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: BSA FTF Subject: [Fwd: MultipleExceptions - a summary] Content-Type: multipart/mixed; boundary="------------410DECE4BFF8512FE8C593D7" X-UIDL: [)=e9 To: John_W_Quillen@sbphrd.com, Karl Konnerth , "Douglas S.Greer" , Jeroen Coppieters , mpetrin@concept5.com cc: Scott Markel , "Dickson, Mike" , W_David_Benton@sbphrd.com, Alan Robinson , Philip Lijnzaad Subject: MultipleExceptions - a summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mozilla-Status2: 00000000 Dear (FTF-)voters, Last night you noticed a hot exchange of mails between me and Scott Markel. It seems that we both need an external help. Therefore, I am writting you this more "personal" mail to ask you for a bit of your time and your opinions on the issue "MultipleExceptions". Because there was quite a lot of mails about it and because there is little time, I decided to put together the argumentation into one mail. I hope that it saves you time. I very appreciate your attention and involvement. You may (correctly) feel that we at EBI consider this issue "an emergency" - we trully think that leaving this issue unsolved makes the BSA spec less valueable - which we feel would be sad. The problem - explanation ------------------------- I am talking about MultipleExceptions used in two methods, one of them is: AnalysisInstance create_analysis (in CosPropertyService::Properties input) raises (CosPropertyService::MultipleExceptions); This method is used to send inputs to an analysis. Each input is defined by metadata (mandatory attributes are name, type and mandatorness). If there is anything wrong with one or more inputs, the MultipleExceptions is thrown. The reasons of the exception can be expressed as one of the following (together with the name of the property which caused the exception): enum ExceptionReason { invalid_property_name, conflicting_property, property_not_found, unsupported_type_code, unsupported_property, unsupported_mode, fixed_property, read_only_property }; The problem we see is that the reasons above do not cover the whole space of possible exceptions. The second problem (which is "only" a design problem and standing alone would not do any harm) is that many of the listed reasons are not useful for our purposes: "property_not_found" is a very good and useable reason; "conflicting_property" is also a good reason, however, we would prefer to have an aditional explanation what exactly is in conflict; "unsupported_type_code" may be probably used for situation that a metadata for an input dictates one type but the client sends the input in a different type - again reasonable reason; However, we do not see usage for other reasons (I think that they were designed for cases where a set of properties is created or updated by clients, which is not our case, we are using only pre-defined properties names - only filled with different values). On the other side, there may be other reasons of invalid input data which a server needs to send back to the clients. Some of the examples are: - the input value is out of the allowed range, - the data defined in the input value are not accessible (it may happen when the input is actually another object) because of this or that reason, - the client did not send some mandatory inputs. The problem - summary --------------------- The usage of MultipleExceptions from the CORBA PropertyService does not cover the whole range of reasons for invalid inputs, and therefore does not allow the server to express what's wrong with client's input data. Which is a serious omission. The proposed resolution - discussion ------------------------------------ The resolution should cover larger range of reasons. It may be achieved either by enumerating all known reasons, or by adding a string to express a reason in a non-structured way, or by combination of both. We feel that ANY of these three solutions help. We may just prefer not to have _only_ enumeration of reasons just because some servers may find additional reasons we do not know about now. But still it would be better to have at least more reasons than the ProperetyService gives us now. We are proposing "the combination of both" because we believe that it can satisfied both the "type-safe" purists and "human-readable" clients (at the end, it is anyway the server implementator who decides what is sent back - so it can use the non-structured string, or predefined enums). But we are prepared to be quite flexible in this. The proposed resolution - (finally) ----------------------------------- 1) To change (in DsLSRAnalysis module) raising CosPropertyService::MultipleExceptions (which occurs in two places) to raising MultipleExceptions. 2) To add to DsLSRAnalysis module the following: enum ExceptionType { conflicting_property, property_not_found, unsupported_type_code, property_is_mandatory, property_is_not_repeatable, property_value_not_accessible, property_value_out_of_range, unsupported_property_value }; struct PropertyException { string reason; ExceptionType type; CosPropertyService::PropertyName failing_property_name; }; typedef sequence PropertyExceptions; exception MultipleExceptions { PropertyExceptions exceptions; }; WHAT CAN BE DONE NEXT? ---------------------- We will vote on the issue soon. But - if you feel that the issue is important and we have/had not enough time to discuss it and to explain different options, we may also postpone (again) the deadline of the FTF report. I am not in favor of such prolongation - but the priority (for EBI) is to have a generally useable specification for running various analysis. If this can be achieved only by having a new deadline, then... (not to appealing idea I must admit). Thank you for your patience to read it all, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger