Thanks for the response. I have a couple of thoughts:
1) serviceType="Catalog" is the same as catalogRef elements, that is true, *but* what I was trying to express is that the datasets that are available via dods are also available as THREDDS catalogs. You have deleted that information -- in your version, datasets are only available as DODS datasets. And deleting the suffix part destroys the compact representation of compound services for servers that uses suffixes, i.e. ingrid and typed-file servers (http,ftp, etc, with a fileextension convention), and servers that have query-based urls with one tag that distinguished the format of the response. I only had two services to make the example clear -- many servers are going to have multiple services, that was the point, and I have many more services that could be described once THREDDS matures. For example, a lot of clients are written to COARDS -- I can generate metadata and datasets that conform, though frequently that is a poor description of the data. But if the client insists, and THREDDS allows the constraint, the servers and clients could communicate. The metadata tag is really a set of services for metadata (i.e. metadata as DIF, etc), which you are certain will alway be multiple.
I am also concerned about XYZT clients (4D
world view) -- how can I protect them against higher (and other)
dimensional data (ensemble member count, spectral, different kinds of time
(forecast start, lead, target time)? I could convert to multiple
datasets, or spatial grids, but it would be nice to advertise the service.
As well as supporting various binary and ascii data formats. Or the
THREDDS dataset (as opposed to collection/catalog) description...
2) The access for the dataset LEVITUS94 is again via THREDDS (the present collection) or via DODS (the access statement). Adding another dataset inside the collection called "Daily" is not the same meaning at all.
3) I thought multiple documents was more analagous to to multiple datasets within a collection, leaving documentation as the unnamed tag within a collection. I am also concerned about having names for datasets and titles for documentation -- seems unnecessarily confusing to give different names to the same concept in different contexts. But documentation tags work for me as well as document tags.
So can we go back to the suffix attribute? And multiple services? Datasets as collections, or access allowed as an subelement of a collection? (After all, why not be able to serve collection metadata in multiple ways?)
Compound does not have to be the only service with sub services: perhaps you should restructure DODS as a service with das,dds,dods,info,ascii subservices? Likewise for OpenGIS?
While I have not given examples, different datasets will have different services, which is why I kept specifying using the access tag. Some datasets will be incompatible with certain representations, so the service lists will vary. One could argue that the THREDDS standard collection is a dataset not available via DODS -- certainly that is the case for me.
John Caron wrote:
Hi Benno, et al:
I am working over your example. I have changed it to conform with my latest
draft DTD at
This is still a strawman, to see how things would look. I have attached
modified versions of
The main issues these examples bring up:
1. Its not clear that allowing compound service (service elements within
service) is useful. The problem is that it may be unlikely that you can use
the same urlPath with multiple services. If you cant, then you need to
specifiy multiple access elements anyway. In your example, the <service
serviceType="Catalog" suffix="thredds.xml"/> seems redundant with the
2. Im not sure the suffix is needed if you dont have compound service
elements, since you can just put the suffix explicitly om the urlPath.
3. I am trying to see how your example looks keeping collection and
dataset seperate. So I just changed the access element on the collection to
a dataset (I wasnt sure what to call it, I called it "DAILY"). In this
design, if a collection is also a dataset, you just explicitly list it as a
dataset. This seems to us to be simpler then making a collection a dataset,
but im open to further discussion.
4. I looked at the XLink spec closer, and added some more XLink semantics
to documentation element. At this point I think these can handle what you
were trying to do with "document" element. I wrote up some descriptions at
have a close look at "documentation" vs "metadata" elements.
Here is Benno1.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE catalog SYSTEM
<catalog name="Benno" version="0.6">
<service ID="IngridDataset" serviceType="DODS"
<attribute name="suffix" value="dods"/>
<collection name="LEVITUS94" serviceID="IngridDataset">
<documentation>LEVITUS94: World Ocean Atlas 1994, an atlas of objectively
analyzed fields of major ocean parameters</documentation>
<attribute name="fullname" value="LEVITUS94"/>
<attribute name="references" value="Conkright:etal1994 Levitus:Boyer1994a
<dataset name="DAILY" urlPath="SOURCES/.LEVITUS94/"/>
<dataset name="ANNUAL" urlPath="SOURCES/.LEVITUS94/.ANNUAL/" />
<dataset name="MONTHLY" urlPath="SOURCES/.LEVITUS94/.MONTHLY/"/>
<dataset name="SEASONAL" urlPath="SOURCES/.LEVITUS94/.SEASONAL/"/>
----- Original Message -----
From: "Benno Blumenthal" <address@hidden>
To: "John Caron" <address@hidden>
Cc: "THREDDS" <address@hidden>
Sent: Thursday, May 30, 2002 10:03 AM
Subject: New attempt
> Hi John,
> Sorry for the moving target, but I have tried again.
> My THREDDS examples are again
> for the top of the tree, and
> for a sample underneath. My only intentional deviation from 6a was to
> add a document element (named version of documentation).
> Could that element be added, or is there a better way to include
> associated html documents with a dataset?
> Is this the way we are going?
-- 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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.