Talk:Version response: Difference between revisions
From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary |
No edit summary |
||
(3 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
<pre> | <pre> | ||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | ||
<Hyrax version="1.4.0"/> | <Server-Version> | ||
<DAP version="3.2"/ | <Hyrax version="1.4.0"/> | ||
<BES version="3.6.2" name="bes" prefix"/"> | <DAP version="3.2"/> | ||
<BES version="3.6.2" name="bes" prefix"/"> | |||
<module name="hdf4_handler" version="3.7.9"/> | |||
<module name="netcdf_handler" version="3.7.8"/> | |||
</BES> | ... | ||
<OLFS version="1.4.0"/> | </BES> | ||
<OLFS version="1.4.0"/> | |||
</Server-Version> | |||
</pre> | </pre> | ||
Why the condensed form? It's easier to read and holds virtually all the same information. Most 'users' of this will be people, like us, trying to debug a server and interested in the versions of software it includes. For users that are machines, it's easy to write a SAX parser (or use a simple string search) to find the DAP protocol number. | Why the condensed form? It's easier to read and holds virtually all the same information. Most 'users' of this will be people, like us, trying to debug a server and interested in the versions of software it includes. For users that are machines, it's easy to write a SAX parser (or use a simple string search) to find the DAP protocol number. | ||
''Notes'': | '''Notes''': | ||
# The order of the elements at the top-level doesn't matter | # The order of the elements at the top-level doesn't matter and neither does the order within the BES element. | ||
# The DAP protocol included is the highest version only - most clients will not parse this looking for version numbers since client writers rarely do that stuff and servers SHOULD provide backwards compatibility. In the worst case, a server that advertises DAP 3.2 will return Error responses for a client that says it can only understand a lower version of the DAP (e.g., 2.0). | # The DAP protocol included is the highest version only - most clients will not parse this looking for version numbers since client writers rarely do that stuff and servers SHOULD provide backwards compatibility. In the worst case, a server that advertises DAP 3.2 will return Error responses for a client that says it can only understand a lower version of the DAP (e.g., 2.0). | ||
# The current response calls the top-level element ''OPeNDAP-Version'' but in reality, it should be ''Server-Version'' since this response is about the versions of stuff in a server - it might not be OPeNDAP's server. |
Latest revision as of 22:22, 31 July 2008
I think the DAP 3.1 Version response XML should be changes to look like:
<?xml version="1.0" encoding="UTF-8"?> <Server-Version> <Hyrax version="1.4.0"/> <DAP version="3.2"/> <BES version="3.6.2" name="bes" prefix"/"> <module name="hdf4_handler" version="3.7.9"/> <module name="netcdf_handler" version="3.7.8"/> ... </BES> <OLFS version="1.4.0"/> </Server-Version>
Why the condensed form? It's easier to read and holds virtually all the same information. Most 'users' of this will be people, like us, trying to debug a server and interested in the versions of software it includes. For users that are machines, it's easy to write a SAX parser (or use a simple string search) to find the DAP protocol number.
Notes:
- The order of the elements at the top-level doesn't matter and neither does the order within the BES element.
- The DAP protocol included is the highest version only - most clients will not parse this looking for version numbers since client writers rarely do that stuff and servers SHOULD provide backwards compatibility. In the worst case, a server that advertises DAP 3.2 will return Error responses for a client that says it can only understand a lower version of the DAP (e.g., 2.0).
- The current response calls the top-level element OPeNDAP-Version but in reality, it should be Server-Version since this response is about the versions of stuff in a server - it might not be OPeNDAP's server.