[MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

David González Pisano dgpisano at cnb.uam.es
Mon Sep 26 23:11:21 UTC 2005


I am attaching a PDF file (faster conversion from Word, the HTML is 
generating is too MS-centric, but we can publish the final approved 
version in HTML). Is as strong rewrite (version 2), but I am still 
maintaining the proposal basics and the specification changes. Basically 
the document is organized in a different way.

Hope this help everybody to take a decision or further improve the  
specification (or both) ;-)

David
(about to dissapear some days for ECCB05)

Martin Senger escribió:

>>I think we can still vote today, as far as Martin's objections are not 
>>really about the proposal itself, but about the aesthetics and 
>>presentation of the proposal
>>
>>    
>>
>   No, I disagree. The proposal is correct in the spirit, but incorrect or
>unclear in details (which I named in my email). The only aesthetics part
>was about the format. That on its own would not give me right to suggest
>to postpone the vote.
>
>  
>
>>Explanations would not make the document *more* difficult to understand 
>>
>>    
>>
>   well the document has about ten pages; but it introduces only few XML
>tags, plus a page of error codes; I think that having it more consice
>helps to make sure that we are not overlooking some missing or
>contradicting point.
>
>  
>
>>See, we can choose between PDF, RTF, ASCI text, HTML, OpenOffice 
>>format...
>>
>>    
>>
>   As I said, this was not my major concern. So do as you wish. I would
>probably prefer an ASCII, or HTML - because that's how the rest of Biomoby
>API is written now.
>
>  
>
>>concerned about using open or closed tools, OMG publishes specifications 
>>in Word format
>>
>>    
>>
>   Talking about OMG, it is even worse that you think. The submissions
>must be in FrameMaker which is completely close format. This is a
>long-time living issue on the OMG table... But that's not our cup of tea.
>
>  
>
>>Anyway I don't have access to the bugzilla
>>
>>    
>>
>   My personal opinion: don't even try - it's easy to be lost there. I did
>not find how to vote there anyway.
>
>  
>
>>Do you have any specific proposal here?
>>
>>    
>>
>   I just wanted to have the codes explained. The last version I saw (the
>one from bugzilla) still has the client codes there. And I do not
>understand what they mean.
>
>  
>
>>Added a new optional Notes element under serviceNotes to separate human 
>>readable free text from structured XML mobyException. This way we can 
>>maintain old functionality into serviceNotes. API changes proposed too.
>>
>>    
>>
>   How can I see the new version?
> 
>  
>
>>Added a new section with API changes needed. Your question was answered 
>>in the proposal which is in the bugzilla but in short yes, still an 
>>empty result has to be sent
>>
>>    
>>
>   But that was under-documented from the beginning. Because the API does
>not say what an "empty integer" means. I hoped that we will use this
>chnage to clarify this.
>
>  
>
>>Hope that you change your mind. As soon as you tell me which document 
>>format you want, I'll send the latest version with the changes commented 
>>above.
>>
>>    
>>
>   Please send it. I will try to read it as it arrives - (but it's already
>close to midnight here so I do not know if I manage it :-)).
>
>   Regards,
>   Martin
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0501INB-ExceptionReporting-v2.0.pdf
Type: application/pdf
Size: 106970 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgpisano.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20050927/3d2f2d1c/attachment-0001.vcf>


More information about the MOBY-dev mailing list