John Caron wrote: > heres another strawman, incorporating our latest discussions: > > http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6d.dtd > > Recent changes: > .... 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? 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. Dan > > 1) Collections as datasets. Ethan and I think the cleanest way to allow > "collections as datasets" is to allow nested datasets. Collections remain > just groups of datasets. A Collection as a dataset is done as a dataset with > nested datasets. Nested dataset elements (Joe's meaning #2) should imply (in > some way we need to clarify better) nested datasets (Joe's meaning #1 and > #3). > > 2) allow compound services again. I have talked myself into that these will > be often useful. > > 3) services are now contained within any collection, rather than having to > be all in the top catalog element. They are scoped by the collection they > are in (so we no longer use ID, since those are global). This makes a > catalogRef have (almost) the same semantics as a collection. > > 4) a catalog now only has exactly one collection element. (i considered > eliminating catalog but i think its better this way). > > 5) "attribute" changed to "property" (tired of saying "the attribute > attribute") > > 6) access element can specify an absolute URL with a serverType -or- a > reletive URL with a serverID. > > Unless I get a barrage of objections, I will document this in more detail > ASAP. I will be gone for a week starting next Tuesdy, so Ethan will continue > the conversation as needed. Hopefully, we can converge soon and take a > break! I think I have incorporated all the good ideas i have heard in this > discussion. Have I left out something, or do you think any feature is not > worth the complexity?