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

Re: latest Catalog XML



 
----- Original Message -----
From: "Benno Blumenthal" <address@hidden>
To: "THREDDS" <address@hidden>
Sent: Friday, June 07, 2002 7:54 PM
Subject: Re: latest Catalog XML

> Quoting John Caron <address@hidden>:
>
> >
> > 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).
> >
>
> This does not quite work for me, unless you allow a catalog to contain exactly
> one collection or exactly one dataset.   Right now the only thredds thing that
> can be pointed to is a catalog, with the added provision that a catalog with one
> collection is effectively that collection -- I would like to point to datasets
> with thredds, which requires either that a catalog can point to a dataset or a
> collection, or that you extend collection to be isomorphic to dataset.   The
> catalog modification would be preferable.
 
hmm i see the problem of an added collection level when using catalogRef.
 
The (minor) problem with
 
  <!ELEMENT catalog (collection | dataset)>
 
is that you wont be able to make it completely seamless. You will have to assume that a catalogRef is a collection, until the user selects it and you read it in. Then you find out its a single dataset. So the user will have to select it again if they want. I think this is equivalent, from the user POV, of opening the collection and seeing a single dataset. Using the previous convention that eliminates the catalogRef collection, it seems this is the same, so I dont think you actually gain any functionality.
 
Perhaps there are other reasons to allow a catalog be a single dataset. I dont yet see any strong reasons not to, but I think in your case Benno, there may not be an advantage.

>
> > 6) access element can specify an absolute URL with a serverType -or- a
> > reletive URL with a serverID.
> >
>
> If you are going to have a base element in service, it is only fair that you
> have a suffix element, too.  Please leave the suffix element in.
>
 
does anyone object to this?