Daniel Holloway wrote:OK
>
> ....
>
> I've used the DTD listed above to create two examples of what
> I believe I could return in an XML-based dods-dir response. The
> catalogs represent simple directory representations of dods-accessible
> data; level1.xml is a higher-level directory containing only subdirs
> and level2.xml is one of the subdirs containing the dods-accessible
> datafiles.
>
> Both of these files validate, I get some warnings but mostly
> due to style issues, there are no errors. These examples represent
> the minimum information that I could provide, there are ways I
> could augment this service to provide some of the additional fields
> represented in the DTD but this example is meant to illustrate a
> minimum set.
>
> Points to note:
>
> 1: I'd need to provide 2 service elements, one for
> type = DODS, and one for type = Other, where Other represents
> the dods-dir service. In many cases there will be both datafiles
> and subdirectories in a file system. Do I need to have two
> service elements? If so, in the 'Level2.xml' example how do
> I indicate which service to use without adding an explicit
> access element for each dataset element?In each dataset element you can indicate the service it uses with the
serviceName attribute; its value would be the same as the value of the service
elements name attribute.
Actually I'm trying to reference a THREDDS catalog, that is, my intention
> 2: I use 'collection' as a simple filesystem collection, there
> may not be any meaningful relation between the files contained
> in the directory other than they're accessible via the DODS DAP.
>
> 3: Am I using 'catalogRef' correctly? The intention is to
> indicate another collection level that should only be traversed
> at the user's request.catalogRef should reference a THREDDS catalog. Yours is referencing a dods-dir
page. I've reworked and attached your examples (with fewer years in level1.xml
and fewer example datasets in level2.1985.xml).
I may be misreading the examples which have been provided in earlier
messages, but it seems that all of the 'hrefs' in the catalogRef examples
use explict filenames, but as long as the response to the 'href' returns
a valid THREDDS catalog representation, why can't the 'href' reference
a service which returns such a catalog. The use of 'service'
in this
case is somewhat different than the 'access' service that is encoded
in the service element, though arguably there is the 'other' and 'catalog'
types.
If you allow this, then the catalog becomes much simpler for the dods-dir
case, basically following my initial example. Actually,
I'm not sure how
the THREDDS API or any other parsing application would know the
difference in the href so long as it returned a valid xml representation.
I think the example you provided below using both dataset and
catalogRef elements to depict the filesystem layout is somewhat
ambiguous since the relation between these two elements is
implicit in this use, and not explicit in the DTD, such that any
API and or parsing application would need to recognize this
particular relationship.
A minor point but I'd prefer not to point to individual 'level#.xml' files in1) I changed the catalogRefs in level1.xml to point to the level2.*.xml files.
The catalog I'm representing with the dods-dir response is a view
2) I added datasets in level1.xml that give access to the dods-dir pages.
3) I added a serviceName attribute in the dataset elements in the level2.*.xml
files.A few alternatives:
1) You could have just one level. Each year could be a collection that contains
the individual datasets.
My plan is to augment dods-dir to return an xml-encoded response, hopefully2) Again, just one level. Each year is a dataset with the dods-dir access and
contains sub-datasets for each individual dataset.I'm working on the THREDDS catalog generator tool. Currently I'm working on
expanding DODS file servers into THREDDS catalogs. After I get that working I'd
like to work on crawling dods-dir pages. So, I'll be wanting to pick your brains
on this stuff.
------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE catalog SYSTEM "http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6d.dtd">
<catalog name="htn_sst_decloud" version="0.6d">
<collection name="htn_sst_decloud/">
<service name="URI-DODS" serviceType="DODS"
base="http://dods.gso.uri.edu/dods-3.2/nph-dods/"/>
<service name="DODSdirectory" serviceType="Other"
base="http://dods.gso.uri.edu/dods-3.2/nph-dods/"/><dataset name="DODS_dir of htn_sst_decloud/1985/"
serviceName="DODSdirectory"/>
<catalogRef xlink:title="htn_sst_decloud/1985/"
xlink:href=""/>
<dataset name="DODS_dir of htn_sst_decloud/1986/"
serviceName="DODSdirectory"/>
<catalogRef xlink:title="htn_sst_decloud/1986/"
xlink:href=""/></collection>
</catalog>------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE catalog SYSTEM "http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6d.dtd">
<catalog name="htn_sst_decloud/1985" version="0.6d">
<collection name="htn_sst_decloud/1985">
<service name="URI-DODS" serviceType="DODS"
base="http://dods.gso.uri.edu/dods-3.2/nph-dods/"/>
<service name="DODSDirectory" serviceType="Other"
base="http://dods.gso.uri.edu/dods-3.2/nph-dods/"/>
<dataset name="k85001182828.htn_d" serviceName="URI-DODS"
urlPath="htn_sst_decloud/1985/k85001182828.htn_d.Z"/>
<dataset name="k85001182828.htn_d" serviceName="URI-DODS"
urlPath="htn_sst_decloud/1985/k85002181750.htn_d.Z"/>
</collection>
</catalog>