[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?

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.