Re: [Psidev-ms-dev] mzML comments

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

On Wed, Aug 27, 2008 at 1:58 AM, Wilfred H Tang <
Ta...@ap...> wrote:

>
> * When m/z vs. intensity data is written out in profile mode, it is pretty
> common to see a LARGE majority of the intensities to be zero. Given the
> preponderance of zero intensities, a space-efficient way to write the data
> out would be to specify a point spacing in the m/z dimension and then write
> out a (m/z, intensity) pair only if the intensity is non-zero. (Call this
> method 1.) The alternative, less space-efficient way would be to write out
> all of the (m/z, intensity) data pairs even though most of them have zero
> intensities and hence are not all that interesting. (Call this method 2.)
> For method 1 to work well, there must be a way to specify a m/z point
> spacing. Is there a way to do this currently? Furthermore, the program
> reading in the mzML must understand that the m/z point spacing implicitly
> requires reconstruction of all the zero-intensity data pairs; otherwise, for
> example, a mass spectrum plot would look funny. A further complication for
> method 1 is that the m/z point spacing may not necessarily be a constant.
> For example, for the AB/Sciex QSTAR instrument, the m/z spacing is
> proportional to the square root of m/z, and this is a natural consequence of
> this being a TOF instrument.
>

Two points:
1) compression should make file size concerns (relatively) moot.
2) including the zeros makes reading in documents (and translation to/from
other formats) much easier. I just don't see the cost/benefit ratio being in
favor of adding this sort of complexity to the standard.



>
> * The validator expects elements to appear in a certain order. This is due
> to the usage of xs:sequence in the XSD file. All deviations from the
> specified order are marked as errors, and I don't think that this is really
> the desired behavior. There's nothing intrinsic to XML that makes
> restricting order desirable, and in most cases for mzML, there is absolutely
> nothing to be gained by restricting order.
>

Three points:
1) Order of elements is intrinsic to XML and always has been. It makes XPath
travesal an implementation possible.
2) As Fredrik mentions in a later email, SAX parsing strategies are made
easier due to the current ordering of elements.
3) Ordering of elements makes writing mzML documents easier.

Cheers,
angel