Your point is well taken: there is a simplicity and explicitness in only allowing full urls. Downside is a bit mixed, I guess.
1) The servicelist concept becomes useless: one has to explicitly list all the services for each dataset, which could either make thredds documents much larger or discourage servers from advertising a large range of services.
2) clients already know how to construct urls (a DODS client constructs a DODS url, a THREDDS client constructs a query for a catalog server): the level of complexity added by giving some ability to construct the rest of the url may not be too bad.
3) While different providers have different ways of mapping datasets, I think the combination of baseurls, subpaths, and suffixes covers a lot of ground (cgi-parameters fall into the suffix catagory, for example).
Benno
Joe Wielgosz wrote:
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
-- Dr. M. Benno Blumenthal address@hidden International Research Institute for climate prediction Lamont-Doherty Earth Observatory of Columbia University Palisades NY 10964-8000 (845) 680-4450