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

[Florian R. <fl...@eb...>]

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



Matt Chambers wrote:
> Hi Florian,
> 
> You might do better to customize the interface for binaryDataHandler in 
> order to provide the array data as an Object that may be a Float[], 
> Double[], Int32[], Int64[], and now String[]. Relying on your users to 
> convert byte[] to the desired array type is a bit harsh, especially if 
> it's compressed. But just having them check the type of the array before 
> doing anything with it is easy and convenient. :)
> 
> -Matt
> 
> 
> Florian Reisinger wrote:
>> Hi,
>>
>> due to requests for jmzml, the Java API for mzML we developed in the PRIDE team, we had to deal with 
>> the 'binary' data elements in the BinaryDataArray.
>>
>> The default JAXB mapping of the xsd:base64Binary type to Java results in a byte[], which seems to 
>> cause troubles when trying to convert with standard base64 algorithms as it does not produce the 
>> expected result.
>>
>> I had to add an extension to the mzML schema defining the binary type to be of type "text/plain" 
>> (see below), so the Java mapping would result in a String representation of the binary data instead 
>> of a byte[]. The byte[] obtained from that String can then be converted to/from base64binary without 
>> problem.
>>
>> The change in the schema is as follows:
>>
>> original:
>> <xs:element name="binary" type="xs:base64Binary"/>
>>
>> modified:
>> <xs:element name="binary" type="xs:base64Binary" xmime:expectedContentTypes="text/plain" 
>> xmlns:xmime="http://www.w3.org/2005/05/xmlmime"/>
>>
>>
>> Now, I was wondering if someone else has experienced similar issues or if someone can see issues 
>> with this modification of the schema (is there a potential issue with the schema specs? or should it 
>> be defined in more detail in case there might be issues with other tools as well?).
>>
>> Also, I am not a expert in XML/Java mapping, so if there is an alternative/preferred way to handle 
>> this type of data, I would be happy to know about it.
>>
>> Thanks,
>> Florian
>>   
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev