[MOBY-dev] [moby] Re: Suggestion for newtag in Parameter(Secondary Input specification)

[Mark Wilkinson]

Hi Paul, 

Could you collect together the various ideas that have come up in this
thread and present a formal proposal?  

Cheers! 

M



On Tue, 2006-02-28 at 08:09 -0700, Paul Gordon wrote:
> Given that the size of the human genome exceeds the limits of a xsd:int, 
> and that we often use e-values exceeding the limits of xsd:double, may I 
> suggest that we mandate the equivalents to xsd:integer and xsd:decimal?  
> I have built my jMOBY code using arbitrary precision numbers, but I'm 
> sure we'll need to change other parts of it, and of the Perl libraries...
> 
> >I think we should choose the corresponding XML Schema types for each 
> >primitive object. For instance:
> >
> >moby:String -> xsd:string (it would not allow XML content) or 
> >xsd:anyType (any content)
> >
> >moby:Integer -> xsd:int [-2147483648,2147483647] or xsd:integer (*any* 
> >integer)
> >
> >moby:Float -> xsd:double (IEEE double-precision 64-bit floating point 
> >type), xsd:float (IEEE single-precision 32-bit floating point type) or 
> >xsd:decimal (*any* real number with a finite number of decimal digits)
> >
> >moby:DateTime -> xsd:dateTime
> >
> >moby:Boolean -> xsd:boolean or an enumerated xsd:string 
> >{'0','1','false','true'}
> >
> >	Best Regards,
> >		José María
> >
> >Paul Gordon wrote:
> >  
> >
> >>The main problem:
> >>
> >>If somebody specifies a float, can I legally submit a e-value cutoff 
> >>like "1.0e-180" (i.e. are we going to assume bit capacity, such as 
> >>2^-149 for 16-byte IEEE floating point, or are we supporting arbitrary 
> >>precision)? Underflow and overflow can cause problems on many 
> >>systems...  same thing for integers > 2^32...
> >>
> >>Actually, do we support scientific notation?  That isn't mentioned either.
> >>
> >>Cheers,
> >>Paul
> >>
> >>P.S. Yes, you are right Pieter.  You could enumerate integers, or even 
> >>floats for that matter: this distinction matters for a server with 
> >>strong types, but not for the client.  I've been too client centric 
> >>lately :-)
> >>
> >>    
> >>
> >>>On Mon, 2006-02-27 at 23:44 +0100, Pieter Neerincx wrote:
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>Hmmm I use enum for some integers as well. I think it's perfectly  
> >>>>normal to say for example: enum [1,2,4,8].
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>Perhaps Paul can clarify what problem he is trying to solve.  My
> >>>instincts tell me that maybe he is having difficulty with casting un-
> >>>typed XML blocks as either Integer or String, as appropriate... is that
> >>>a correct interpretation of the problem Paul?  
> >>>
> >>>I think the combination of the <datatype> block and the <enum> block
> >>>should be able to indicate whether the ENUM is of type String or of type
> >>>Integer (or Float, or whatever).  Is that not sufficient?  Or am I
> >>>misunderstanding what the root of the problem is?
> >>>
> >>>M
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>MOBY-dev mailing list
> >>>MOBY-dev at biomoby.org
> >>>http://biomoby.org/mailman/listinfo/moby-dev
> >>> 
> >>>
> >>>      
> >>>
> >>_______________________________________________
> >>MOBY-dev mailing list
> >>MOBY-dev at biomoby.org
> >>http://biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
> >>    
> >>
> >
> >  
> >
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev
-- 

--
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

"For most of this century we have viewed communications as a conduit, 
       a pipe between physical locations on the planet. 
What's happened now is that the conduit has become so big and interesting 
      that communication has become more than a conduit, 
       it has become a destination in its own right..."

                Paul Saffo - Director, Institute for the Future