You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the workshop it was brought up by Bob Hanson that there is no easy way to detect the OPTIMADE json api format. It would also be beneficial if identification was possible from data at the top of the file. He suggested an alternate format where the json api part is wrapped by an array where the first part is a "header" from which the format can be identified.
After discussion it was concluded that:
The present version of the OPTIMADE format can be detected by looking for the meta -> api_version field, and further confidence is given by the data array containing type fields matching the expectation (e.g., structures).
We should in a future version add as a MANDATORY field in meta named ~ standard that MUST point to a URL under schemas.optimade.org.
(Neither of these does match the desire of identification without reading the full file. @rartino proposed to make it mandatory for the json api data array to contain as first element a type:header item.)
The text was updated successfully, but these errors were encountered:
While not ideal, I agree that this is the simplest, least disruptive approach. Thank you! Working now to get Jmol to read the entire file in the case of suspect JSON files.
Jmol 14.32.59 now identifies an optimade data stream by the presence of one of "cartesian_site_positions":, "api_version":, or optimade in the first 16K bytes (or in the full file when the JSON Object initial "magic byte" character { is present as the first character of the stream). This should be suitable for general purposes and is not a significant load on general file loading for Jmol. Suggestion of ["optimade at the start of the stream is moved to "concatenated OPTIMADE" issue.
During the workshop it was brought up by Bob Hanson that there is no easy way to detect the OPTIMADE json api format. It would also be beneficial if identification was possible from data at the top of the file. He suggested an alternate format where the json api part is wrapped by an array where the first part is a "header" from which the format can be identified.
After discussion it was concluded that:
meta -> api_version
field, and further confidence is given by the data array containingtype
fields matching the expectation (e.g.,structures
).standard
that MUST point to a URL under schemas.optimade.org.(Neither of these does match the desire of identification without reading the full file. @rartino proposed to make it mandatory for the json api data array to contain as first element a type:header item.)
The text was updated successfully, but these errors were encountered: