[personal] Re: [MOBY-dev] [RFC] Exception Reporting in bioMOBY v1.5 - INB proposal

[Mark Wilkinson]

On Wed, 2005-08-31 at 02:23 +0100, Martin Senger wrote:

> 2) I suggest to resolve it (accept or refuse) before September 15 (so
> this is an RFC calendar). Concretely, I propose that Mark will ask
> selected voters after this date to vote on it.

OK.  I will be on holiday that day in the mountains (likely with no net
access even from my cell phone) so perhaps David or Martin can call the
vote in my absence?


>  (BTW, I like and
> support his idea to have a year-long tenure on the voting list (that's
> actually very close why OMG has its Architecture Board also with
> rotating, and *dedicated*, people).

Super!  I'll try to write-up a formal "constitution" document in the
next few days...



> 1) The attribute names 'Value' and 'Description' are not
> intuitive. They should express more what they are about. What about
> "errorCode" (or only "code") and "errorMessage" (or only "message")?

I agree.


> 2) I know that the article name in Simples in Collection is an
> optional part of the proposal - but I agree with Mark that using there
> again the term "articleName" is bad (too overloaded). What about to
> use there a completely different tag, like "elementId"?

I think I proposed this alternative as well. I do have a deeper concern,
however, and I want to discuss this thoroughly before we make any
decisions here.  

It isn't entirely clear to me that there is a need to throw errors on a
specific Simple within a Collection.  This is very complicated for me to
explain clearly, but I will try...  A collection is a "semantic unit" -
it is the response to a ***single*** input.  As such, it cannot be
partially erroneous!  It is either entirely erroneous, or entirely
correct.  To throw an error on a single sub-unit of a collection casts
doubt on the validity of the entire collection (since you cannot
interpret what the collection would have "looked like" had that error
not been thrown) and thus the entire collection must be considered
flawed.

Imagine it this way:  What would it mean to have a Blast report where
certain HSP's within the Blast report contained error messages?  Does it
mean that there was a sequence in the underlying database that was
somehow incorrectly formatted  If so, then the blast provider should
have caught that error and not reported that match at all rather than
telling the client that there is a flakey sequence in their database.
Does it mean that the software is buggy?  If so, then the entire report
is potentially flawed, and should not have been produced.  Does it mean
that (in some way) the input sequence was peculiar?  If so, then again
the entire output is suspect and not just a single HSP within that
output.

Do you see what I am getting at?  The scenario we are trying to
accommodate, in my opinion, is impossible if people are using
Collections in the way they are intended to be used.


> 3) I would like to have (in the exception API handling) a remark that
> the clients are obliged to be aware that a service can also raise an
> exception that will be delivered in the SOAP envelope (that is a
> standard way). As I said, good clients have to do it anyway (because
> your service does not have always full control what to return back) -
> so I would keep this option there.

Absolutely!

M



-- 
"Ontologists do it with the edges!"

Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274