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

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

Jimmy makes an excellent point: some textual representations would be
more useful than others.

As far as I know, whitespace is whitespace in XML, so I would hope that
producers of mzData files would choose whitespace to enhance the
readability of the file.

I wasn't really thinking it through, but the "ideal" representation I've
been assuming in my head would look something like this

	<peaklist>
   	123.4 123
	125.3 123343
	127.4 23423
	</peaklist>

Obviously, as Brian points out, the form that splits the mz and
intensity lists isn't as friendly

	<mzArray>
	123.4
	125.3
	127.4
	</mzArray>

	<intenArray>
	123
	123343
	23423
	</intenArray>

I think someone mentioned something like this

	<peaklist>
		<peak><mz>123.4</mz><inten>123</inten></peak>
		<peak><mz>125.3</mz><inten>123343</inten></peak>
		<peak><mz>127.4</mz><inten>23423</inten></peak>
	</peaklist>

which is better than the second but not as good as the first above.
This seems more XML-ish than the above two format (or the current binary
arrays), at the expense of being very verbose.

With judicious addition of whitespace, this could made more readable (at
a further cost in size)

	<peaklist>
		<peak><mz> 123.4 </mz><inten>    123 </inten></peak>
		<peak><mz> 125.3 </mz><inten> 123343 </inten></peak>
		<peak><mz> 127.4 </mz><inten>  23423 </inten></peak>
	</peaklist>


Personally I'd be quite happy with the first form (at the top of this
post).  It may be slightly lacking in XML purity, but it's very
readable, and it's clear what its semantics should be.  The only real
disadvantage I see is that it's a little different than the current
mzData scheme, which breaks mz and intensity into separate lists.

Mike