[MOBY-dev] RFC #1863 - change request & question

[Martin Senger]

> 1. I have a problem with callling all of this Error Handling and having 
> the tag called mobyException, when this mechanism includes not only 
> errors, but also non-fatal warnings and simple information blocks.  
>
   I think this was caused by me: I have asked the authors to have there
also simple information blocks. I see now that having two places for the
same informations (a mobyException tag with a simple information, and the
Notes tag) may be confusing. So I am fine with not having the type 
'information' there).
   On the other hand, I think that having warnings in the mobyException is
correct (I consider a warning as an exceptional condition).

> 2. Under "Service Intrinsic Errors", the footnote for 701 states that 
> Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR.  Why is 
> getting no hits an error?
>
   I think that this is an example. Simply it refers to a service that 
*consider* this situation as exceptionla and errorneus. Your service may 
feel differently. But if you think that such example is confusing, it is 
simple to remove it (or to replace is by an another one).

>     "700 OK" (pretty obvious: everything was okay, but we want to 
> provide a formatted  info block in the response)
>
   But you can always use Notes to fo that withoutr having any 
exceptionMoby block at all. I am not sure what you want to achiev by this 
700 code I must admit.

>     "703 Data no longer valid" (once upon a time the data was valid, but 
> no longer: a sequence identifier that has been retracted, a job ticket 
> that is stale, etc.)
>     "704 input invalid" (somehow you escaped the 200 series errors 
> because it is MOBY-correct input, but biologically the input doesn't 
> make sense e.g. an EC number is an object with a String, and that's what 
> you gave us, but the string is HelloWorld, which is not of the form #.#.#.#)
>     "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA 
> search)
>
   We surely can make more service-specific codes. But I feel that having
them is not anyway rich enough - the service providers may specify more
details (e.g. yout 704 woulod by better to say why it is invalid; and if
not then the code 201 should be used).  So I would keep the pre-defined
700 codes at minimum (anyway, what a client can do with them? it simply
reports it - there is probably no general way how to send the same request
again with the error corrected).
   I would even remove 701 and rename 702. See below.


   My additional comments to the latest draft are:

   * Make sure that upper/lower cases are consistent in attribute names. I 
notices that refqueryId is spelled both ways as: refQueryId and 
refqueryId.

   * I think that we do not need Error code 701. The general failure is 
reported by 600, and nayhinf more specific can have a concrete 
service specific code (documented in the service description).

   * Code 702 is either too generic (so some of 200 codes should be used
instead ) or a service provider should be more specific and agin design
its specific code and document it. But The example for this code is quite
useful - even so useful that I would suggest to add a code for
"not-matching namespace" condition (either as a 70x code, or perhaps as a 
227 "INPUT_INCORRECT_NAMESPACE".

   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger at gmail.com
   skype: martinsenger
consulting for:
   International Rice Research Institute
   Biometrics and Bioinformatics Unit
   DAPO BOX 7777, Metro Manila
   Philippines, phone: +63-2-580-5600 (ext.2324)