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

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,
> 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
> subdirectories, e.g. a filter which transforms the metadata to be COARDS
> compliant  would mean appending   COARDS/   to the dataseturl.  There are
> filters for averaging, svd analysis, etc, but I was not trying to go there
> 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
2) add a urlsuffix attribute to service element, meaning "append this to
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
> files: I only include it as an example and probably would not advertise
> 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).

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.