Re: [Psidev-ms-dev] attributes vs cvParams

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

Lennert and Matt,

While I appreciate that this is a topic of great interest to everyone in the
community, let's turn the heat down a bit. Let me see if I can play the
arbiter here:

cvParams since their introduction have always been contentious. Given the
choice for design of a data formate where attributes (or sub elements or
inner text) could be encoded with a tight set of enumerated sets of values
vs. empty slots, a developer will always choose the former.

Why then did the mzML group choose cvParams? The answer is two fold: 1) the
audience,  and 2) the intent of the standard

1) Name one standard that has received industry support across multiple
vendors/tools/institutions that is tightly controlled with enumerated
values. Prove me wrong, but I can't think of any.

The reasons for this is that consensus building is a slow process and
approval of any change in a data format can take months if not years. You
need flexible data formats for standards. This already rules out enumerated
values, but you can also make the case that vendors are unwilling to tie
their development efforts to projects that are not under their complete
control (essentially motivated by risk management). As a vendor, if you
officially support even on release of a fast moving data format, customer
expectations are such that you are now expected to support all future
releases of that format.

2) The intent of mzML is data transfer and vendor independent storage of
mass spec experimental data. It is not (officially) meant to be an
operational format. Operational formats would put much more weight on the
side of enumerated values.


So for theses reasons (there are more though) cvParams are not going to go
away. As for actually doing work with mzML files, Matt is absolutely right,
this is going to be way more difficult than working with mzXML 2.x (as a
developer) While OLS is a fine andd dandy project, it is not the end-all
be-all solution to our problems. It assumes network connectivity, which is a
dubious assumption. Even assuming very fast connectivity, the overhead of
SOAP protocols are waaaayyy too big to except in your typical use of mzML
files, which are signal processing and searches.  Please stop equating OLS
with mzML (or any other ML) since for most uses outside of a repository it
just won't work. -a