[Nexus-developers] API state

[Akeroyd, FA (Freddie)]

If "type" -> "NAPItype" in the XML NeXus file format then should the DTD
format also use "NAPItype" rather than "type"? I guess it would be nice
to have the DTD and native XML file formats as similar as possible, but
it is not strictly necessary and using "NAPItype" everywhere in the DTD
might look a bit ugly - thoughts?

Freddie

> -----Original Message-----
> From: nexus-developers-bounces at anl.gov [mailto:nexus-developers-
> bounces at anl.gov] On Behalf Of Peterson, Peter F.
> Sent: 20 May 2005 13:49
> To: nexus-developers at anl.gov
> Subject: FW: [Nexus-developers] API state
> 
> I agree with Freddie on hiding special attributes from the NAPI user.
> The precedent that was set in Switzerland was to prefix the attribute
> with "NAPI". So it would be "NAPItype".
> 
> What do you (Mark) think of this change and removing the special
> attributes from the listing of attributes for a field?
> 
> P^2
> 
> -----Original Message-----
> From: nexus-developers-bounces at anl.gov
> [mailto:nexus-developers-bounces at anl.gov] On Behalf Of Akeroyd, FA
> (Freddie)
> Sent: Friday, May 20, 2005 7:54 AM
> To: nexus-developers at anl.gov
> Subject: RE: [Nexus-developers] API state
> 
> The XML interface uses the XML attribute "type" to store the data type
> of an item - this is treated as a real attribute by
> NXgetattrinfo/NXgetnextattr so if you convert a file from HDF -> XML
you
> appear to gain an attribute. As the "type" attribute is special I
think
> it should be hidden from the user who calls
NXgetattrinfo/NXgetnextattr
> and also if the user tried to set "type" via NXputattr they should get
> an error. In fact, protecting "type" is important because a user could
> legitimately set an attribute called "type" in HDF which would cause
> problems when the file was converted to XML. I guess a similar
argument
> applies to the "target" attribute too - we should really prefix all
> NeXus special internal attributes with something ("nx","_", ...) and
> then disallow setting of attributes with this prefix from the usual
> interface.
> 
> I've made the search for "libsz.a" better in configure; does that
help?
> 
> Freddie
> 
> > -----Original Message-----
> > From: nexus-developers-bounces at anl.gov [mailto:nexus-developers-
> > bounces at anl.gov] On Behalf Of Mark Koennecke
> > Sent: 20 May 2005 10:19
> > To: nexus-developers at anl.gov
> > Subject: [Nexus-developers] API state
> >
> > High everyone,
> >
> > I fixed the issue with the XML-API by now. It actually was much more
> > serious, the XML-API was reading wrong numbers. Nobody noticed....
> > This was a bug in mxml which
> I
> > resolved. Thus, the only
> > version of mxml which works is 2.2.2 as released yesterday!
> >
> > There is another issue with the test not working under SL 3.0.4 and
> Suse
> > Linux 9.2. Now, I spent a lot
> > of time with this. The first result was that the test programs would
> > fail within libc if hdf5 was involved.
> > I tried various ways to improve on this by trying to initialize the
> hdf5
> > library before use. The hdf5 library is used even if hdf4 or xml
files
> 
> > are read in order to test if a given
> file
> > is hdf5. The hdf team told me that there is no other  means of
testing
> 
> > for hdf5, no magic number. I obtained
> the
> > best result when I put a
> > H5open into the top of the test program napi_test.c. My next guess
was
> 
> > to run strace upon the problem. For non unix guys: strace traces in
> > much detail all system calls. This showed me that the segfault  was
> > right after  a call to munmap. Apparantly Linux memory maps files
for
> > reading. I also ran the program through valgrind, a very thorough
> > memory debugging program. This yielded no errors in our code or the
> > hdf*, xml libraries.
> > I am now coming to the conclusion that the problem is in libc or
gcc,
> > both of which I do not wish to debug.
> > If someone experiences the problem she should update both gcc and
libc
> 
> > to newer (or older?) versions.
> >
> > There is still a small issue with the build process if you build a
> > version including a recent version of hdf4 but no hdf5. Then the
-lsz
> > is missing on the link. This can be overcome by setting LDFLAGS to
> > "-Lpath-to-you-szlib -lsz" before running configure.
> >
> >  What do you think?
> >
> >                                          Mark
> >
> >
> >
> > _______________________________________________
> > NeXus-developers mailing list
> > NeXus-developers at anl.gov
> > http://www.neutron.anl.gov/mailman/listinfo/nexus-developers
> 
> 
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at anl.gov
> http://www.neutron.anl.gov/mailman/listinfo/nexus-developers
> 
> 
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at anl.gov
> http://www.neutron.anl.gov/mailman/listinfo/nexus-developers