[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: latest Catalog XML



Sorry,

    That email got away from be while attaching the examples,
here they are:

Dan

p.s.  I don't think I need the two service elements so I removed
        the second already, serviceType=Other

Daniel Holloway wrote:

> 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?
<?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/"/>

      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1985/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1985/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1986/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1986/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1987/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1987/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1988/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1988/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1989/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1989/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1990/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1990/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1991/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1991/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1992/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1992/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1993/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1993/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1994/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1994/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1995/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1995/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1996/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1996/"/>
      <catalogRef xlink:type="simple"
                  xlink:title="htn_sst_decloud/1997/"
                  
xlink:href="http://dods.gso.uri.edu/dods-3.2/nph-dods/htn_sst_decloud/1997/"/>
   </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" 
urlPath="htn_sst_decloud/1985/k85001182828.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85002181750.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85003180718.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85004063159.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85005174650.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85006061233.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85007074057.htn_d.Z"/>
     <dataset name="k85001182828.htn_d" 
urlPath="htn_sst_decloud/1985/k85009170625.htn_d.Z"/>
  </collection>
</catalog>

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.