[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Catalog XML Draft

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
address@hidden / (707)826-2631
---------------------------------------------------
Center for Ocean-Land-Atmosphere Studies (COLA)
Institute for Global Environment and Society (IGES)
http://www.iges.org