Re: [Psidev-ms-dev] mzML base64binary data type question

[Angel P. <an...@ma...>]

OK, so think I am reading this completely wrong, but isn't the default JAXB
base64binary to byte[] decoding preserve the zlib compression, resulting in
a byte[] that is still zlib compressed? If so the java.util.zip.Inflater
should handle this correctly to deflate the byte[] before translating it
into Float[],  int[] whatever.
My AS3 parser (soon to be released) encounters the same issue and I also
have deflate the byte[] before reading into an Array of Number (same data
type for double or float in AS3).

Am I missing something? -angel

On Mon, Jun 15, 2009 at 10:45 AM, Florian Reisinger <fl...@eb...>wrote:

> Hi Matt,
>
> maybe I did not express myself well enough.
>
> We do have methods that take care of converting the data from the base64
> encoded XML data into a
> more convenient double[] in Java. Taking into account the CVParams for
> precision and compression,
> this will actually hold double or float values. The user can then check if
> the actual data contained
> in the array is in double or float values...
> (I still have to cater for the int and String representations, though)
>
>
> But what I am having trouble with is the data I read from an existing mzML
> file. We used the default
> JAXB generated mapping and the data stored by the Unmarshaller in the
> mapped byte[] variable does
> not seem to be base64 encoded. It seems the data in the XML is not
> correctly converted into the Java
> byte[], which renders my attempts to base64-decode it useless.
>
> With the changes I mentioned to the XML schema, the mapping changes and the
> data is now unmarshalled
> into a String variable. The byte[] obtained from this String is base64
> encoded and if converted into
> double/float I get reasonable values...
>
>
> Cheers,
> Florian
>
>
>
>