NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
John, Benno, A high-level question related to the base URL/suffix discussion:How much effort should THREDDS put into supporting particular data provider site layouts?
I initially thought base URLs and relative paths were a nice feature (they would certainly be convenient for GDS catalogs) but upon reflection, I wonder if they aren't more trouble than they are worth.
If you look at different data providers websites, they all have their own way of mapping datasets, collections and access methods to URLS, and some are quite complex. They might use any combination of different base URLs, subpaths or suffixes, CGI parameters, or who knows what else.
You could try to support some, or even all, of these mappings in the catalog DTD---but it increases the complexity of the DTD and the THREDDS client API, and I am not sure what benefit THREDDS users get in return, other than the catalog files being a little more concise.
On the other hand, I see a definite client benefit to leaving out relative URLs and other mapping schemes - if URLs are always absolute, a <dataset> tag and its <access> sub-tags can be interpreted unambiguously, without having to poke through the rest of the catalog file. IMHO, this would make the catalog format much more robust and make client development easier.
And I see a couple ways that the information represented in base URLs could be catalogued more usefully: - If the provider wants to give a URL for information about a collection or service, it should be in a <documentation> tag. - If they want to provide direct data access to an entire collection as a single data object, it should be in an <access> tag.
Thoughts, comments? - Joe John Caron wrote:
Proposed changes to the THREDDS catalog format are at: http://www.unidata.ucar.edu/projects/THREDDS/tech/InvCatalog6.html The current format is documented at: http://www.unidata.ucar.edu/projects/THREDDS/tech/InvCatalog5.html Summary of changes: a.. add <attribute> elements to collection, dataset, service b.. rename "server" element to "service". c.. add new service types: (DODS | ADDE | NetCDF | Catalog | FTP | OpenGIS | WSDL | Other) . d.. allow multiple services per dataset: add <access> child element of dataset, where you list any number of services for that dataset, and add <serviceList> element so you can define a list of services. "serviceId" now refers to either a service or a serviceList. Use a serviceList when the same dataset urlPath can be appended onto all service bases. e.. generalize <datasetDescRef> element to <metadataRef>, where "DatasetDesc" is one of several metadata types. proposed types: (DatasetDesc | DublinCore | DIF | ADN | FGDC | LAS | Other) f.. add "ID" and "alias" attributes to dataset, so that a dataset can be an alias to another dataset. Please send comments to me or to this list.
-- Joe Wielgosz joew@xxxxxxxxxxxxx / (707)826-2631 --------------------------------------------------- Center for Ocean-Land-Atmosphere Studies (COLA) Institute for Global Environment and Society (IGES) http://www.iges.org
thredds archives: