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

Re: netCDF DTD

>To: address@hidden
>From: Bear Giles <address@hidden>
>Subject: Re: 20000302: netCDF DTD
>Organization: .
>Keywords: XML, ncxdump, ncxgen

Hi Bear,

> The attached tarball contains a revised DTD and a quasi-working
> ncxgen.  I say "quasi-working" because the byte and character
> routines seem to be, ah, wrong. :-)  But the data is allocated,
> numeric data looks reasonable, etc.

Thanks for the update!  I've updated the DTD at

  http://www.unidata.ucar.edu/packages/netcdf/dtd/giles-dtd

and will make your new tarball available as

  ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/xml-tools.tar.gz

and list it in the directory of contributed software at

  http://www.unidata.ucar.edu/packages/netcdf/contrib.html

unless you tell me otherwise.

> One potential problem is that I'm currently allocate a sizeable
> temporary buffer.  Once the program works, we need to either 
> make the main data parser work incrementally in the cdata handler
> or replace the legacy <value> tag with something that breaks the
> data into smaller chunks.  The most obvious technique is
> <1d-array>, <2d-array>, ..., or we could introduce an artificial
> <tick> element that tells the system to process all data up
> to this point (which essentially requires the same logic as
> incremental processing, albeit with a clearer defined trigger.)

Other people are encountering this problem with XML representation of
large datasets also.  You might want to read the short section near
the bottom of this whitepaper on XDF "On the binary, ascii, mark-up
debate", and the subsequent section on "Direct access" also:

  http://tarantella.gsfc.nasa.gov/xml/XDFwhite.txt

I haven't thought about it or researched it enough to have a
well-informed opinion yet.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu