Re: [Psidev-ms-dev] honey vs vinegar

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

On 10/4/07, Jimmy Eng <jk...@gm...> wrote:
>
> Angel, counter to what you're suggesting, I do believe that mzML was
> developed to at least try and be an operational format also.
> Otherwise, there would not be a need for a scan index with file offset
> pointers in the wrapper schema, no?


Very true. And I hope that decent performance comes from the API's written
for the format. I am playing devils advocate here. Call me a pessimist, but
I don't think any instrument manufacturer is going to use mzML as their
native format (Or at least it will take on the order of 4 or more years for
this to happen). If vendors do adopt it as the native format, great! I would
be more than ecstatic, but I am not holding my breadth.

Vendors, please correct me if I am making a wrong assumption here. Silence
== agreement ;)

The primary reason why mzXML was developed was to replace native MS
> binary data files with something transparent and platform neutral (and
> be an operational format for tools that consume these files).
> Obviously everyone imagines mzML to address many, and it looks like
> sometimes different & non-inclusive, use cases.  My short sighted
> personal interest is to see mzML address the operational raw file
> replacement use case succinctly w/o any adverse complexities to make
> its adoption for this use case difficult.  Otherwise Angel's proposal
> of mzML->SRF, mzML->mgf, and I dare say mzML->mzXML is going to end up
> being reality for some subset of users.  And in the world of these
> users, why bother going from native->mzML->XYZ if native files are
> around and you can do native->XYZ?


My hope is that by having mzML in the middle, we can reliably say SRF ==
MGF, where with the current situation of native -> XYZ, we just can't make
that claim. Also, it is my hope to reduce the burden of 3rd party vendors by
having mzML be the officially supported format for input.

-angel