Re: New Catalog XML Draft -- example

----- Original Message -----
From: "Benno Blumenthal" <address@hidden>
To: "John Caron" <address@hidden>; <address@hidden>
Sent: Wednesday, May 15, 2002 1:11 PM
Subject: Re: New Catalog XML Draft -- example


> Hi John,
>
> An example would certainly be in order.   Within Ingrid/IRI data library,
the
> url for a dataset is a virtual directory, different files within that
> directory contain the different representations of that dataset, e.g.
> dods.das, dods.dds, dods.dods,   data.cdf,  data.r4,  data.s4, data.txt,
> index.html,  index.xml, .... .   Filters on the data and metadata appear
as
> subdirectories, e.g. a filter which transforms the metadata to be COARDS
> compliant  would mean appending   COARDS/   to the dataseturl.  There are
also
> filters for averaging, svd analysis, etc, but I was not trying to go there
at
> the moment.
>
> To describe this as a serviceList, I would envision something like the
> following:
>
> <servicelist  ID="Ingrid" base="http://iridl.ldeo.columbia.edu/";>
> <service type="DODS"  urlsuffix="dods">
> <service type="DODS" subtype="COARDS" urlsuffix="COARDS/dods">
> <service type="netcdf" urlsuffix="data.cdf">
> <service type="netcdf" subtype="COARDS" urlsuffix="COARDS/data.cdf">
> </servicelist>
>
> ...
> <collection name="LEVITUS94">
>  <collection name="ANNUAL">
>             <dataset name="PO4" serverID="Ingrid" dataType="GRID"
> urlPath="SOURCES/.LEVITUS94/.ANNUAL/.PO4/"/>
>            <dataset name="NO3" serverID="Ingrid" dataType="GRID"
> urlPath="SOURCES/.LEVITUS94/.ANNUAL/.NO3/"/>
>            <dataset name="temp" serverID="Ingrid" dataType="GRID"
> urlPath="SOURCES/.LEVITUS94/.ANNUAL/.temp/"/>
>
> ...
>         </collection>
>
> ...
> </collection>
>
> .....
>
>
> And I would hope the client would generate DODS base urls like
>
> http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.ANNUAL/.PO4/dods
>
> or
>
> http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.ANNUAL/.PO4/COARDS/dods
>
> depending on whether it wanted the COARDS subtype or not.

So you have added a few new twists to the proposed <serviceList> element:

1) allow servicelist to have a base attribute, which its service elements
inherit.
2) add a urlsuffix attribute to service element, meaning "append this to
URL".
3) add a subtype atttribute to service element, meaning
   3.1 "display this to the user so they can choose" ?? in which case you
probably want a subtype on the other element, which in this case would mean
"raw - not augmented with COARDS" ?

(or) 3.2 "clients should know which service they want and filter
accordingly" (client = software client).

The last question is really more general than subtypes, its really what does
a client do when it sees multiple services for the same dataset?


>
>
> One could envision large service lists, so one might want to allow doing
it by
> reference (would only have to download a servers servicelist once).
>
> Benno
>
> P.S.   the 'netcdf' service above refers to http delivery of complete
netcdf
> files: I only include it as an example and probably would not advertise
the
> service since I would rather clients use DODS anyway.

Actually, service="NetCDF" currently means Netcdf access (including
subsetting) through HTTP, which is in the Netcdf-Java library (version 2).
We'd have to name your service something different (its more like FTP except
over HTTP).