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

Re: JDOM Parsing error



Daniel Holloway wrote:

address@hidden wrote:

I have a proposal to make:

Is it possible that we want to have only one standard (the AggServer version)?

The argument is as follows.  Suppose someone is describing a set of dods urls
that correspond to different times.   They have no intention of running an
AggServer, so they confine themselves to the InvCatalog dtd.  Wouldn't we be
better off if they had described the collection in the AggServer format, so that
we would then be able to detect that aggregation is the appropriate thing to do
with the collection, and to describe/index/present it to the user accordingly.
Or, if the software does not aggregate, just present the collection, nothing
lost relative to the InvCatalog description.
I think it could be a powerful notion to combine these two, but i havent thought through all the consequences yet.

It seems that what you are proposing is to try to allow the specification of how the datasets in a collection are precisely related, eg "time series". This idea has also come up from the IDV group. With this you can do essentially "client side aggregation".

Here are some possible problems:

1. On the agg server, the aggregation files can be local, ie not available individually from the server. More generally, I would like to add a mechanism to allow the server to create views of datasets; the underlying implementation of those views could be hidden from the client.

2. AS config more or less assume the DODS/netCDF data model. But THREDDS catalogs allow datasets using services other than DODS, so the meanings of aggregated datasets may be less clear.

3. The AS config can add various XML elements that are specific to the AS and DODS, without worrying about confusing things for non-AS users.


I tend to agree with Benno on this, though the one standard may end
up being slightly different than the current AggServer version.  My concern
is that the current InvCatalog description isn't extensive enough to be
much more than a simple list which in the long run isn't sufficient to
represent a true catalog.  I realize that work is underway to develop
queriable catalogs, if possible that effort should try to merge the
existing Aggregation descriptions into those catalogs since in some
sense there are clear similarities with building multi-dimensional
aggregations of simpler types and traversing organizational hierarchies
represented in catalogs to uniquely identify data granules of
interest.

Dan

I am more or less ready to start thinking about catalog version 0.7. If I understand what you are thinking, you want to provide the same functionality as dodsdir ? Can you give specifics of that?