[MINC-users] minc2 api question

[EJ Nikelski]

Hi List,

    I had a question concerning the operation of a subset of minc2
functions, which I believe I posted a few weeks ago -- although I'm
now wondering if the post may have been lost.  So, just to be sure
that it got out, let me throw it out again (pls forgive the redundancy
if the first one did get out).


========== start previous post

   I've been writing some minc2 code, and have run into a problem
when retrieving attributes from a minc2 volume.  For example, say that
I wanted to get information on attribute "xspace:varid" (just as an
example).  If I were to start by retrieving the length of the
attribute by calling miget_attr_length, I would get a no-find returned
since miget_attr_length starts all attribute searches relative to
/minc-2.0/info.  Any path passed to miget_attr_length is simply
appended to /minc-2.0/info.  Therefore, call like this :

result = miget_attr_length(minc_volume, "/minc-2.0/dimensions/xspace",
"varid", &attr_length);

 ... would result in /minc-2.0/info/minc-2.0/dimensions/xspace being
searched for attribute "varid" (and subsequently not found).  The code
that causes this behaviour can be found in a number of miget_attr_xxx
functions, and therefore most other attribute related functions
similarly are unable to find requested attributes.  Now I know that
the API has specialty functions to retrieve all sorts of attributes,
however, I had assumed that one should be able to use the
miget_attr_xxx functions to retrieve any or all of the attributes --
and not just those in /minc-2.0/info/.  Is this assumption incorrect?

  By the way, I modified some of the miget_attr_xxx functions on my
system to respect an absolute path when passed (and not prepend
/minc-2.0/info/), which worked ... but broke other things (including
the minc2 "make check", amongst other things) ... so beware, as some
code assumes the current behaviour.

  Any comments/suggestions on this stuff would be welcome.


-Jim