Nit in VOTABLE precision attribute

[Tom McGlynn (NASA/GSFC Code 660.1)]

[Not sure if this is the right group but...]

We've been running into a problem with validation of one of our SSA services and I believe this 
shows an inconsistency
between the text of the VOTable standard and the schema.

The problem is that we occasionally use the fields where we want a floating point value, but we 
expect that the values
will normally be integral -- e.g., we might have a time of observation field which is given in MJD.  
In some tables we
may only have the MJD itself, so the there will be no fractional part to the time (in units of days)/


So we use <FIELD .... precision='F0' > which expresses this precisely.  In the text of the standard, 
2.3 paragraph 3, the precision
is noted as being 'semantically identical' with the TDISP keyword in fits file.  In FITS it is 
perfectly legal
to have a TDISPnn = 'F12.0'.  This derives in turn from Fortran formatting conventions where this 
was common practice.

In 4.2 the text is:

The precision attribute is meant to express the number of significant digits, either as a number of 
decimal places (e.g. precision="F2" or equivalently precision="2" to express 2 significant figures 
after the decimal point), or as a number of significant figures (e.g. precision="E5" indicates a 
relative precision of 10–5).

So F0 would express that there a no significant digits to the right of the decimal point --- which 
seems perfectly natural.


The problem is in the schema where the construct:
<xs:simpleType name="precType">
   <xs:restriction base="xs:token">
     <xs:pattern value="[EF]?[1-9][0-9]*"/>
   </xs:restriction>
</xs:simpleType>

specifically precludes the value F0.  I believe E0 might logically be forbidden -- it implies no 
significant figures -- but maybe not. That's a common occurrence
in actual data.  In any case I believe the exclusion of F0 is an erratum in the schema since it 
specifically contradicts an authoritative though perhaps non-normative statement
in 2.3, and seems a common and desirable implementation of what is described in 4.2.


     Regards,
     Tom McGlynn