Contents
Note
Most of the following warnings indicate violations of the VOTable specification. They should be reported to the authors of the tools that produced the VOTable file.
To control the warnings emitted, use the standard Python warnings module. Most of these are of the type VOTableSpecWarning.
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.
vo.table always outputs files using only spaces, regardless of how they were input.
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.
VOTable 1.2 corrects this error in the specification.
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.
It is further recommended in the VOTable 1.2 spec:
While the ID attribute has to be unique in a VOTable document, the name attribute need not. It is however recommended, as a good practice, to assign unique names within a TABLE element. This recommendation means that, between a TABLE and its corresponding closing TABLE tag, name attributes of FIELD, PARAM and optional GROUP elements should be all different.
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 (such as whitespace) with underscores.
Note
This warning does not indicate that the input file is invalid with respect to the VOTable 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.
The attribute must be a valid URI as defined in RFC 2396.
This warning is emitted when a ucd attribute does not match the syntax of a unified content descriptor.
If the VOTable version is 1.2 or later, the UCD will also be checked to ensure it conforms to the controlled vocabulary defined by UCD1+.
As astro year field is a Besselian or Julian year matching the regular expression:
^[JB]?[0-9]+([.][0-9]*)?$
Defined in this XML Schema snippet:
<xs:simpleType name="astroYear">
<xs:restriction base="xs:token">
<xs:pattern value="[JB]?[0-9]+([.][0-9]*)?"/>
</xs:restriction>
</xs:simpleType>
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 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.
The parser has encountered an element that does not exist in the specification, or appears in an invalid context. Check the file against the VOTable 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 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 non-standard datatype names. These are mapped to standard ones using the following mapping:
string -> char
unicodeString -> unicodeChar
int16 -> short
int32 -> int
int64 -> long
float32 -> float
float64 -> double
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.
A DESCRIPTION element can only appear once within its parent element.
According to the schema, it may only occur once (1.1, 1.2)
However, it is a proposed extension to VOTable 1.2.
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 or 1.2.
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.
Raised when the VO service database can not be updated (possibly due to a network outage). This is only a warning, since an older and possible out-of-date VO service database was available locally.
The VO catalog database retrieved from the www is designed for a newer version of vo.table. This may cause problems or limited features performing service queries. Consider upgrading vo.table to the latest version.
A VO service query failed due to a network error or malformed arguments. Another alternative service may be attempted. If all services fail, an exception will be raised.
The given element was not supported inside of the given element until the specified VOTable version, however the version declared in the file is for an earlier version. These attributes may not be written out to the file.
The COOSYS element was deprecated in VOTABLE version 1.2 in favor of a reference to the Space-Time Coordinate (STC) data model (see utype and the IVOA note referencing STC in VOTable.
The given attribute was not supported on the given element until the specified VOTable version, however the version declared in the file is for an earlier version. These attributes may not be written out to the file.
Some VOTable files specify their version number in the form “v1.0”, when the only supported forms in the spec are “1.0”.
Some VOTable files write missing floating-point values in non-standard ways, such as “null” and “-”. In non-pedantic mode, any non-standard floating-point literals are treated as missing values.
Since NaN’s can not be represented in integer fields directly, a null value must be specified in the FIELD descriptor to support reading NaN’s from the tabledata.
Each field in a table must have a unique ID. If two or more fields have the same ID, some will be renamed to ensure that all IDs are unique.
From the VOTable 1.2 spec:
The ID and ref attributes are defined as XML types ID and IDREF respectively. This means that the contents of ID is an identifier which must be unique throughout a VOTable document, and that the contents of the ref attribute represents a reference to an identifier which must exist in the VOTable document.
Each field in a table must have a unique name. If two or more fields have the same name, some will be renamed to ensure that all names are unique.
The attribute requires the value to be a valid XML token, as defined by XML 1.0.
The name and value attributes are required on all INFO elements.
References: 1.1, 1.2
If the field specifies a null value, that value must conform to the given datatype.
References: 1.1, 1.2
The 3 datatypes defined in the VOTable specification and supported by vo.table are TABLEDATA, BINARY and FITS.
References: 1.1, 1.2
The only encoding for local binary data supported by the VOTable specification is base64.
Bit values do not support masking. This warning is raised upon setting masked data in a bit column.
This is a terrible hack to support Simple Image Access Protocol results from archive.noao.edu. It creates a field for the coordinate projection type of type “double”, which actually contains character data. We have to hack the field to store character data, or we can’t read it in. A warning will be raised when this happens.
An XML namespace was specified on the VOTABLE element, but the namespace does not match what is expected for a VOTABLE file.
The VOTABLE namespace is:
http://www.ivoa.net/xml/VOTable/vX.X
where “X.X” is the version number.
Some files in the wild set the namespace to the location of the VOTable schema, which is not correct and will not pass some validating parsers.
The root element should specify a namespace.
The VOTABLE namespace is:
http://www.ivoa.net/xml/VOTable/vX.X
where “X.X” is the version number.
Referenced elements should be defined before referees. From the VOTable 1.2 spec:
In VOTable1.2, it is further recommended to place the ID attribute prior to referencing it whenever possible.
VALUES elements that reference another element should not have their own content.
From the VOTable 1.2 spec:
The ref attribute of a VALUES element can be used to avoid a repetition of the domain definition, by referring to a previously defined VALUES element having the referenced ID attribute. When specified, the ref attribute defines completely the domain without any other element or attribute, as e.g. <VALUES ref="RAdomain"/>
The content-role attribute on the LINK element must be one of the following:
query, hints, doc, location
The given char or unicode string is too long for the specified field length.
If no arraysize is specified on a char field, the default of ‘1’ is implied, but this is rarely what is intended.
The attribute is not defined in the specification.
Empty cell illegal for integer fields.
If a “null” value was specified for the cell, it will be used for the value, otherwise, 0 will be used.
Invalid unit string as defined in the Standards for Astronomical Catalogues, Version 2.0.
Note
This is a list of many of the fatal exceptions emitted by vo.table when the file does not conform to spec. Other exceptions may be raised due to unforeseen cases or bugs in vo.table itself.
The size specifier for a char or unicode field must be only a number followed, optionally, by an asterisk. Multi-dimensional size specifiers are not supported for these datatypes.
Strings, which are defined as a set of characters, can be represented in VOTable as a fixed- or variable-length array of characters:
<FIELD name="unboundedString" datatype="char" arraysize="*"/>
A 1D array of strings can be represented as a 2D array of characters, but given the logic above, it is possible to define a variable-length array of fixed-length strings, but not a fixed-length array of variable-length strings.
The number of array elements in the data does not match that specified in the FIELD specifier.
Complex numbers should be two values separated by whitespace.
A boolean value should be one of the following strings (case insensitive) in the TABLEDATA format:
'TRUE', 'FALSE', '1', '0', 'T', 'F', '\0', ' ', '?'
and in BINARY format:
'T', 'F', '1', '0', '\0', ' ', '?'
The supported datatypes are:
double, float, bit, boolean, unsignedByte, short, int, long,
floatComplex, doubleComplex, char, unicodeChar
The following non-standard aliases are also supported, but in these case W13 will be raised:
string -> char
unicodeString -> unicodeChar
int16 -> short
int32 -> int
int64 -> long
float32 -> float
float64 -> double
The type attribute on the VALUES element must be either legal or actual.
The MIN, MAX and OPTION elements must always have a value attribute.
From VOTable 1.1 and later, FIELD and PARAM elements must have a datatype field.
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).
It is validated using the following regular expression:
[EF]?[1-9][0-9]*
The width attribute is meant to indicate to the application the number of characters to be used for input or output of the quantity.
From the VOTable 1.2 spec:
A table cell can contain an array of a given primitive type, with a fixed or variable number of elements; the array may even be multidimensional. For instance, the position of a point in a 3D space can be defined by the following:
<FIELD ID="point_3D" datatype="double" arraysize="3"/>and each cell corresponding to that definition must contain exactly 3 numbers. An asterisk (*) may be appended to indicate a variable number of elements in the array, as in:
<FIELD ID="values" datatype="int" arraysize="100*"/>where it is specified that each cell corresponding to that definition contains 0 to 100 integer numbers. The number may be omitted to specify an unbounded array (in practice up to =~2×10⁹ elements).
A table cell can also contain a multidimensional array of a given primitive type. This is specified by a sequence of dimensions separated by the x character, with the first dimension changing fastest; as in the case of a simple array, the last dimension may be variable in length. As an example, the following definition declares a table cell which may contain a set of up to 10 images, each of 64×64 bytes:
<FIELD ID="thumbs" datatype="unsignedByte" arraysize="64×64×10*"/>
All PARAM elements must have a value attribute.
All COOSYS elements must have an ID attribute.
Note that the VOTable 1.1 specification says this attribute is optional, but its corresponding schema indicates it is required.
In VOTable 1.2, the COOSYS element is deprecated.
The system attribute on the COOSYS element must be one of the following:
'eq_FK4', 'eq_FK5', 'ICRS', 'ecl_FK4', 'ecl_FK5', 'galactic',
'supergalactic', 'xy', 'barycentric', 'geo_app'
References: 1.1
extnum attribute must be a positive integer.
The type attribute of the RESOURCE element must be one of “results” or “meta”.
Raised either when the file doesn’t appear to be XML, or the root element is not VOTABLE.
The table had only x fields defined, but the data itself has more columns than that.
The table had x fields defined, but the data itself has only y columns.
Warn or raise an exception, depending on the pedantic setting.
Raise an exception, with proper position information if available.
Raise an exception, with proper position information if available.
Restores the original traceback of the exception, and should only be called within an “except:” block of code.
Warn, with proper position information if available.
Parses the vo warning string back into its parts.
Bases: exceptions.Warning
The base class of all VO warnings and exceptions.
Handles the formatting of the message with a warning or exception code, filename, line and column number.
Bases: astropy.io.votable.exceptions.VOWarning, exceptions.SyntaxWarning
A change has been made to the input XML file.
Bases: astropy.io.votable.exceptions.VOWarning, exceptions.SyntaxWarning
The input XML file violates the spec, but there is an obvious workaround.
Bases: astropy.io.votable.exceptions.VOWarning, exceptions.SyntaxWarning
A feature of the VOTABLE spec is not implemented.
Bases: astropy.io.votable.exceptions.VOWarning, exceptions.RuntimeWarning
A network or IO error occurred, but was recovered using the cache.
Bases: astropy.io.votable.exceptions.VOWarning, exceptions.ValueError
The input XML file violates the spec and there is no good workaround.