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

[Mike C. <tu...@gm...>]

On 10/5/06, Brian Pratt <bri...@in...> wrote:
>...the unsuitability of XML for eyeballing what is essentially
columnar data, ...

I do think "eyeballability" is important, but I also feel uneasy
placing the key spectrum data beyond the reach of XML in an XML
spectrum format.  In essence, in the current version the XML encodes
spectrum metadata--the peaks themselves become an afterthought, hidden
away in a relatively inaccessible appendix.

This would be easier to justify if this were image data, for which
there is no reasonable textual representation.  But in this case there
is a trivial representation, and the code to read and write it is
probably simpler than for the base64-encoded case.

There's some discussion here

    http://c2.com/cgi/wiki?IsolateEachDatum

that touches on this issue.  Also, an example on that page suggests
another possibility for the encoding of peaklists that I prefer to
those discussed so far:

<peaklist>
  <peak mz="234.56" i="789" />
  <peak mz="3456.43" i="2" />
  <peak mz="3457.22" i="234" />
</peaklist>

This would have the virtue of being highly accessible to eyeball and
quick-and-dirty scripts as well.  It would also clearly compress well.
 And it keeps the peak data within the realm of XML.  It would be
conceivable, I think, to use XSLT to create a table of peak data or
even an SVG image of the spectrum, for example, since everything would
be living in XML-land.


> ...A standard that provides n>1 ways
> to state the same thing is n times as difficult to implement and maintain,
> which reduces vendor enthusiasm by a factor of n (squared?), which hinders
> widespread adoption. ...

I generally agree with this, and in particular, I suspect that if the
specification allowed both representations, possibly most vendors
would only produce base64 output.  For this reason, if the textual
representation is preferred, maybe the base64 alternative should be
deprecated and marked for removal in a future version.

However, I think that there is still an advantage to having the
textual alternative in the specification, even if instrument vendors
never produce it.  It would allow those of us who prefer the textual
format to do convert to it in a standard way, in a way that
coordinates with the mzData standard.

Mike