Re: [Psidev-ms-dev] Why base64?

[Coleman, M. <MK...@St...>]

> Randy Julian:

> The XML-schema data types where tested by most of the vendors who
> did not see the file size compression benefits you mention because
they did
> not feel they had the ability to round either of the vectors in the
way you
> suggest.

I'm not unsympathetic to this practical concern.  The most important
thing would be to allow the textual representation as an equal variant
(i.e., not buried in the supplemental data section).

I'm not sure I see why generating the textual representation would be
difficult, though.  My guess is that the vendors will continue to use
their own proprietary formats to do the initial recording of data, only
translating to mzData as a final step.  If the final step is carried out
on a platform with a real libc, this looks like it would be
straightforward.


> Just as a note for your comment #3, this is not so straight=20
> forward.  If the instrument collects data using an Intel chip,
floating-point=20
> raw data will most likely have a IEEE-754 representation.  So any time
you=20
> have a number in a file like 0.1, the internal representation was=20
> originally different (0.1 cannot be exactly represented in IEEE-754).
When you=20
> read from the file into an IEEE standard format, it will not be 0.1 in
any of=20
> the math you do.

I agree that this is complicated.  As far as the mzData standard goes,
probably the biggest thing that would help here would be a way for the
data producer to indicate, in the mzData file, their idea of the
accuracy of the measurements.  If I understand correctly, currently this
is implied, or communicated outside of the mzData file.


Please let me add that I think the mzData format is a great improvement
over the array of formats that it's meant to replace.  I'd like this
representation issue to be resolved in the best way possible, but it's
certainly minor in the overall scheme of things.

Mike