<--
VOTable-JSON output discussionAs discussed in the IVOA Interop in South Africa, many of the service providers are either already using, or have thought of using JSON as a complimentary output format for TAP (as well as other data access services). Many large projects such as LSST have often expressed a preference for JSON over XML, and it seems to be worth discussing whether we should, and if so how to propose a votable-JSON standard output for TAP services.
Below are some of the different approaches that have been discussed on the DAL mailing list:
1) Simplistic approach suggested by [Brian McKlaveren, Thomas Boch, Stelios Voutsinas, Grégory Mantelet]{"columns": [ {"name":"foo", "datatype":"int"}, {"name":"bar", "datatype":"long"} {"name":"baz", "datatype":"double"} ], "data" : [ [ 1, "1.12", 2.123] [ 2, "1.34", 2.345] [ 3, "1.56", 2.678] ]
}
Pros:
+ Extremely easy to deal with in javascript + Human Readable
i.e: var table = $(/* call TAP here via jquery */); table.columns.forEach(function(i){ console.log(i.name)}); // log names table.rows.forEach( doSomethingWIthRow );
Cons:
- Missing some metadata? i.e. Query status, overflow, description? (Possible to extend by adding additional metadata in key/array pairs, e.g. "metadata/query/info")
2) XML to JSON conversion using badgerfish [Pat Dowler]"I have written some generic code to output a DOM in JSON in addition to the usual XML. It is a set of rules mostly consistent with http://badgerfish.ning.com/ but with simpler namespace handling and more consistent array/list output. We have it in use in vospace (for sure) and maybe UWS (can't recall if that is released yet). I intend to try outputting VOTable using this code... it will be more complex than the above examples and iirc there are some structures allowed in VOTable that don't map perfectly." <Pat Dowler>
Pros:
+ Output structure will closely match VOTable?
Cons:
- More complex object. May lose some of the simplicity of JSON output.
3) Mapping based on Boost Property Tree [Walter Landry]Based on Boost Property Tree http://www.boost.org/doc/libs/1_60_0/doc/html/property_tree/parsers.html#property_tree.parsers.json_parser
{
"VOTABLE": { "<xmlattr>": { "version": "1.3", "xmlns:xsi": "http:\/\/www.w3.org\/2001\/XMLSchema-instance", "xmlns": "http:\/\/www.ivoa.net\/xml\/VOTable\/v1.3", "xmlns:stc": "http:\/\/www.ivoa.net\/xml\/STC\/v1.30" }, ... "RESOURCE": { "<xmlattr>": { "type": "results" }, "INFO": { "<xmlattr>": { "name": "QUERY_STATUS", "value": "OK" } }, "TABLE": { "FIELD": { "<xmlattr>": { "name": "cntr", "datatype": "int" } }, ... "DATA": { "TABLEDATA": [ [ "224910226", "s", ... ] ] } } } } }
Pros:
+ Direct VOTable (XML) mapping
Cons:
- Similarly to previous example, result is a more complex object. May lose some of the simplicity of JSON output.
Questions to consider:
| ||||||||
Added: | ||||||||
> > | ||||||||
<--
VOTable-JSON output discussionAs discussed in the IVOA Interop in South Africa, many of the service providers are either already using, or have thought of using JSON as a complimentary output format for TAP (as well as other data access services). Many large projects such as LSST have often expressed a preference for JSON over XML, and it seems to be worth discussing whether we should, and if so how to propose a votable-JSON standard output for TAP services.
Below are some of the different approaches that have been discussed on the DAL mailing list:
1) Simplistic approach suggested by [Brian McKlaveren, Thomas Boch, Stelios Voutsinas, Grégory Mantelet]{"columns": [ {"name":"foo", "datatype":"int"}, {"name":"bar", "datatype":"long"} {"name":"baz", "datatype":"double"} ], "data" : [ [ 1, "1.12", 2.123] [ 2, "1.34", 2.345] [ 3, "1.56", 2.678] ]
}
Pros:
+ Extremely easy to deal with in javascript + Human Readable
i.e: var table = $(/* call TAP here via jquery */); table.columns.forEach(function(i){ console.log(i.name)}); // log names table.rows.forEach( doSomethingWIthRow );
Cons:
- Missing some metadata? i.e. Query status, overflow, description? (Possible to extend by adding additional metadata in key/array pairs, e.g. "metadata/query/info")
2) XML to JSON conversion using badgerfish [Pat Dowler]"I have written some generic code to output a DOM in JSON in addition to the usual XML. It is a set of rules mostly consistent with http://badgerfish.ning.com/ but with simpler namespace handling and more consistent array/list output. We have it in use in vospace (for sure) and maybe UWS (can't recall if that is released yet). I intend to try outputting VOTable using this code... it will be more complex than the above examples and iirc there are some structures allowed in VOTable that don't map perfectly." <Pat Dowler>
Pros:
+ Output structure will closely match VOTable?
Cons:
- More complex object. May lose some of the simplicity of JSON output.
3) Mapping based on Boost Property Tree [Walter Landry]Based on Boost Property Tree http://www.boost.org/doc/libs/1_60_0/doc/html/property_tree/parsers.html#property_tree.parsers.json_parser
{
"VOTABLE": { "<xmlattr>": { "version": "1.3", "xmlns:xsi": "http:\/\/www.w3.org\/2001\/XMLSchema-instance", "xmlns": "http:\/\/www.ivoa.net\/xml\/VOTable\/v1.3", "xmlns:stc": "http:\/\/www.ivoa.net\/xml\/STC\/v1.30" }, ... "RESOURCE": { "<xmlattr>": { "type": "results" }, "INFO": { "<xmlattr>": { "name": "QUERY_STATUS", "value": "OK" } }, "TABLE": { "FIELD": { "<xmlattr>": { "name": "cntr", "datatype": "int" } }, ... "DATA": { "TABLEDATA": [ [ "224910226", "s", ... ] ] } } } } }
Pros:
+ Direct VOTable (XML) mapping
Cons:
- Similarly to previous example, result is a more complex object. May lose some of the simplicity of JSON output.
Questions to consider:
|