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
