[kepler-dev] [Bug 1990] New: - DataType of EML for KEPLER

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1990

           Summary: DataType of EML for KEPLER
           Product: Kepler
           Version: 1.0.0beta1
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: tao at nceas.ucsb.edu
        ReportedBy: tao at nceas.ucsb.edu
         QAContact: kepler-dev at ecoinformatics.org


The Datatype really should be determined in EML from the measurementScale and
domain (numericDomain and nonNumericDomain).  Using the storage type was
a hack  that we kept in from our earlier Monarch code -- its very
unreliable, and is optional, which is why we at times have trouble.  I
think I wrote about this in a bug for Kepler, but I can't find it.

The default Ptolemy types are fairly coarse grained, so we should get
fairly far by something simple:

MeasurementScale     numberType        Type
nominal              N/A               string
ordinal              N/A               string
interval/ratio       natural           int or long (depending on bounds)
interval/ratio       whole             int or long (depending on bounds)
interval/ratio       integer           int or long (depending on bounds)
interval/ratio       real              double
datetime                               ?

In the above, you can use bounds and precision to help fine tune which
of the numeric types to use.

In implementing this, its probably best to separate out the type
inference code from the rest as much as possible -- a separate method at
  a minimum, a separate class possibly.   Keep in mind that this code is
probably going to be somewhat related to semantic type checking that
Shawn is working on.