[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: latest Catalog XML
- Subject: Re: latest Catalog XML
- Date: Sat, 8 Jun 2002 11:14:16 -0600
----- Original Message -----
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?