NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: latest Catalog XML

Woops realized that I simply responded to John.

Peter
-- 
 Peter Cornillon                                                       
  Graduate School of Oceanography  - Telephone: (401) 874-6283         
   University of Rhode Island      -       FAX: (401) 874-6728         
    Narragansett RI 02882  USA     -  Internet: pcornillon@xxxxxxxxxxx
--- Begin Message --- 
Hi all,

An interesting discussion. I wrestled a bit with this around the time
of the DODS developers meeting last January. I have attached a table
that I put together to help me keep track of the issues. I think that
you have progressed way beyond this, but thought that you might find
it interesting anyway.

Peter

John Caron wrote:
> 
> heres another strawman, incorporating our latest discussions:
> 
> http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6d.dtd
> 
> Recent changes:
> 
> 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?

-- 
 Peter Cornillon                                                       
  Graduate School of Oceanography  - Telephone: (401) 874-6283         
   University of Rhode Island      -       FAX: (401) 874-6728         
    Narragansett RI 02882  USA     -  Internet: pcornillon@xxxxxxxxxxx
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="GENERATOR" content="Mozilla/4.72 [en] (X11; U; Linux 
2.2.14-6.1.1 i686) [Netscape]">
   <title>Oceanology International </title>
</head>

<BODY bgcolor="#eeeeee" vlink=blue>

<table width="100%" cellpadding=0 cellspacing=2><tr>
<td bgcolor="white"><a HREF="levels.html"><img 
src="../dods-general/next.gif"></a></td>
<td bgcolor="white"><a HREF="definitions.html"><img 
src="../dods-general/up.gif"></a></td>
<td bgcolor="white"><a HREF="definitions.html"><img 
src="../dods-general/previous.gif"></a></td>
<td align="center" bgcolor="#99ccff" width="100%"><font size=7><b>OPeNDAP Data 
Objects, Collections and
Sets</b></td></table>
<p><br><br>

<basefont size=6>
<p>

<ul>
   <li> <font color="red">OPeNDAP Data Objects</font> are the data retrieved by 
any OPeNDAP URL
         (constrained or unconstrained).<br><br>

         <ul><font color="magenta">
             <li>a portion of a satellite image
             <li>a mooring record
         </font>
         </ul><br>

   <li> <font color="red">OPeNDAP Datasets</font> <font color=green>(or OPeNDAP 
Granules)</font>
         are OPeNDAP Data Objects accessed by an unconstrained URL.<br><br>

         <ul><font color="magenta">
             <li>a satellite image
             <li>a mooring record
             <li>a NetCDF file that contains all satellite images in a given 
projection from a specific sensor
         </font>
         </ul><br>

   <li> <font color="red">OPeNDAP Data Collections</font> are collections of 
OPeNDAP
         Datasets that are accessible either <br>

       <ul type=i>
         <li> as a new OPeNDAP Dataset via an OPeNDAP Aggregation Server, or<br>
         <li> as a list of OPeNDAP Datasets via a File Server.<br><br>
       </ul>

       <ul><font color="magenta">
           <li> all satellite images in a given projection from a specific 
sensor
           <li> a collection of mooring records
           </font>
        </ul><br>

        <font color=green>Note that the list of OPeNDAP Datasets accessed via 
an unconstrained
        request to an OPeNDAP File Server is also an OPeNDAP 
Dataset.</font><br><br>


   <li> <font color="red"><blink>NVODS Datasets</blink></font> are all of the 
meteorological 
       or oceanographic data at a site that the data provider considers to be 
logically 
       connected. Could be an OPeNDAP Dataset, an OPeNDAP Data Collection or a 
group of
       OPeNDAP Datasets that are not formally linked from an OPeNDAP 
perspective.<br><br>
       <ul><font color="magenta">
           <li> all satellite images in a given projection from a specific 
sensor for which
                neither an OPeNDAP File Server nor an OPeNDAP Aggregation 
Server exist<br>
           <li> a NetCDF file that contains all satellite images in a given 
projection
       </font>
       </ul>
</BODY>
</HTML>

--- End Message ---
  • 2002 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: