Note
Most of the following warnings indicate violations of the VOTable 1.1 specification. They should be reported to the authors of the tools that produced the VOTable file.
The VOTable spec states:
If a cell contains an array or complex number, it should be encoded as multiple numbers separated by whitespace.
Many VOTable files in the wild use commas as a separator instead, and vo.table supports this convention when not in pedantic mode. Files are always written using only spaces, however.
XML ids must match the following regular expression:
^[A-Za-z_][A-Za-z0-9_\.\-]*$
The VOTable 1.1 says the following:
According to the XML standard, the attribute ID is a string beginning with a letter or underscore (_), followed by a sequence of letters, digits, or any of the punctuation characters . (dot), - (dash), _ (underscore), or : (colon).
However, this is in conflict with the XML standard, which says colons may not be used. VOTable 1.1’s own schema does not allow a colon here. Therefore, vo.table disallows the colon.
The VOTable 1.1 spec says the following about name vs. ID on FIELD and VALUE elements:
ID and name attributes have a different role in VOTable: the ID is meant as a unique identifier of an element seen as a VOTable component, while the name is meant for presentation purposes, and need not to be unique throughout the VOTable document. The ID attribute is therefore required in the elements which have to be referenced, but in principle any element may have an ID attribute. ... In summary, the ID is different from the name attribute in that (a) the ID attribute is made from a restricted character set, and must be unique throughout a VOTable document whereas names are standard XML attributes and need not be unique; and (b) there should be support in the parsing software to look up references and extract the relevant element with matching ID.
Since vo.table requires a unique identifier for each of its columns, ID is used for the column name when present. However, when ID is not present, (since it is not required by the specification) name is used instead. However, name must be cleansed by replacing invalid characters with underscores. ID attributes must match the following regular expression:
^[A-Za-z_][A-Za-z0-9_\.\-]*$
Note
This warning does not indicate that the input file is invalid with respect to the VOTable 1.1 specification, only that the column names in the record array may not match exactly the name attributes specified in the file.
The content-type attribute must use MIME content-type syntax as defined in RFC 2046.
The current check for validity is somewhat over-permissive.
This warning is emitted when a ucd attribute does not match the syntax of a unified content descriptor. The check itself is performed with an overly permissive regular expression. It does not perform any vocabulary control:
^[A-Za-z0-9_\.;\\\-]*$
As astro year field is a Besselian or Julian year matching the regular expression:
^[JB]?[0-9]+([.][0-9]*)?$
To avoid local-dependent number parsing differences, vo.table may require a string or unicode string where a numeric type may make more sense.
The VOTable 1.1 specification uses the attribute name ID (with uppercase letters) to specify unique identifiers. Some VOTable-producing tools use the more standard lowercase id instead. vo.table accepts id and emits this warning when not in pedantic mode.
vo.table has encountered an element that does not exist in the specification, or appears in an invalid context. Check the file against the VOTable 1.1 schema (with a tool such as xmllint. If the file validates against the schema, and you still receive this warning, this may indicate a bug in vo.table.
Earlier versions of the VOTable specification used a gref attribute on the LINK element to specify a GLU reference. New files should specify a glu: protocol using the href attribute.
Since vo.table does not currently support GLU references, it likewise does not automatically convert the gref attribute to the new form.
In order to name the columns of the Numpy record array, each FIELD element must have either an ID or name attribute to derive a name from. Strictly speaking, according to the VOTable 1.1 schema, the name attribute is required. However, if name is not present by ID is, and pedantic mode is off, vo.table will continue without a name defined.
Some VOTable files in the wild use string to specify the char datatype. When pedantic mode is off, vo.table will implicitly convert the FIELD to type char and proceed.
Some VOTable files in the wild use unicodeString to specify the unicodeChar datatype. When pedantic mode is off, vo.table will implicitly convert the FIELD to type unicodeChar and proceed.
The name attribute is required on every FIELD element. However, many VOTable files in the wild omit it and provide only an ID instead. In this case, when pedantic mode is off, vo.table will copy the name attribute to a new ID attribute.
Each FIELD element may only contain one VALUES element.
A DESCRIPTION element can only appear once within its parent element.
The number of rows explicitly specified in the nrows attribute does not match the actual number of rows (TR elements) present in the TABLE. This may indicate truncation of the file, or an internal error in the tool that produced it. If pedantic mode is off, parsing will proceed, with the loss of some performance.
The column fields as defined using FIELD elements do not match those in the headers of the embedded FITS file. If pedantic mode is off, the embedded FITS file will take precedence.
If no version number is explicitly given in the VOTable file, the parser assumes it is written to the VOTable 1.1 specification.
Unknown issues may arise using vo.table with VOTable files from a version other than 1.1.
Version 1.0 of the VOTable specification used the DEFINITIONS element to define coordinate systems. Version 1.1 now uses COOSYS elements throughout the document.