Re: 20000712: a question

• To: Dave Fulker <fulker@xxxxxxxxxxxxxxxx>
• Subject: Re: 20000712: a question
• From: Steve Emmerson <steve@xxxxxxxxxxxxxxxx>
• Date: Mon, 17 Jul 2000 12:38:57 -0600

Dave (et al),

>Date: Mon, 17 Jul 2000 11:52:31 -0600
>From: Dave Fulker <fulker@xxxxxxxxxxxxxxxx>
>To: "Ethan R. Davis" <edavis@xxxxxxxx>,
>To: John Caron <caron@xxxxxxxxxxxxxxxx>
>Subject: Re: 20000712: a question

In the above message, you wrote:

> Hence, I favor option two (building a VisAD adapter directly on the
> DODS classes) ...

I (metaphorically speaking -- not mecessarily me :-) would do both.  It
should be very possible to create a DODS VisAD I/O package.  It should
also be feasible to split the netCDF "bottom end" of the netCDF VisAD
I/O package into a "pure" netCDF-using side and a DODS's server-using
side.  Which side was used could depend on the "pathname" specification.
Once you've beaten you head against one problem, the other should be
half as difficult because of the knowledge you obtained.

> I think this objective remains valid, and perhaps "pluggable semantic
> parsers" could help us get there, though I don't yet understand
> exactly what it means.  I once proposed that Steve's netCDF adapter
> for VisAD could be augmented with a constructor whose signature
> included a text string making the MathType explicit, i.e., replacing
> Steve's intelligent guesswork with knowledge of specific netCDF files
> or conventions.  Is the pluggable semantic parser idea more or less
> equivalent?

I wouldn't do it that way.  Instead, I'd have a programatically-settable
layer above the import layer whose job would be to convert the incoming
data object(s) into something that is known a priori to be more
appropriate for the task at hand.  This would separate the semantics of
the data from the nut-and-bolts of reading it in.

Please, though, don't ask me to do this at this time.  I need to get
some other things straightened away first.

Regards,
Steve Emmerson   <http://www.unidata.ucar.edu>