I realized after I sent my e-mail that I had missed your point, sorry.
John Caron wrote:
I sympathize with this design, but there are a number of subtle issues that
I think we need to clarify before we commit to it. Lets follow your line of
thought, and modify Joe's example to use dataset where he uses entry:<catalog>
<service name="X"/>
<service name="Y"/>
...<dataset name="my_dataset">
<metadata name="global-metadata" url=""/>
<access name="global-X-access"/><dataset name="monthly-data">
<metadata name="monthly-metadata" url=""/>
<access name="X-with-COARDS" serviceType="X" url=""/>
<access name="X-with-no-COARDS" serviceType="X" url=""/>
<access name="X-flattened-to-2D" serviceType="X" url=""http://..." /">http://..."/>
<access name="Y" serviceType="Y" url=""/>
....
</dataset></dataset>
What is the relationship (if any) between the peers
<access name="global-X-access"/>
<dataset name="monthly-data">The same question asked in a different way:
What is the meaning that <dataset name="monthly-data"> is contained in
<dataset name="my_dataset">. Do we expect monthly-data to be a subset of
my_dataset? Do we expect that <access name="X-with-COARDS"/> is some kind
of subset of <access name="global-X-access"/>
Yes, a dataset being inside a dataset is exactly the same meaning
that a dataset being in a collection had.
I am not convinced that access should have a name attribute -- I think that is a mistake -- if different accesses cannot be distinguished by standard values of standard tags, clients are not going to make much use of them, so I think name should not be a standard part of an access. One could allow accesses to have attributes if a server wants to make a non-standard distinction, but I think names should be discouraged. My vision of access was to tell software that it had different ways of accessing the data, not telling users that there were options.
COARDS is actually a bit of a confusing example. It is a metadata standard, however, the problem that I was trying to address is that clients are written such that if the dataset is not structured precisely as COARDS demands, the client will fail (XYZT ordering, for example). That is why I called it a subtype of access, because I wanted to provide an access for clients that require COARDS. Clearly one could also express the service with an attribute of access called metadata-standard -- I have no particular attachment to subtype. We also could have an attribute called worldview: that way 2D clients and 4D clients could express their requirements, and servers might have an opportunity to fulfill them.
One could also solve the problem by having all clients that claim they read DODS to handle anything that can be served with DODS, but there are not too many such clients.
Benno
-- 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