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

[Matthew C. <mat...@va...>]

Thanks Angel, I didn't intend for the discussion to get heated, it just 
seemed to me that Lennart didn't understand what I posted (which may be 
my fault, it's hard to know without other replies).  Remember I posted 
that I agree with cvParams and appreciate the flexibility they provide.  
But there is a difference between cvParams that have meaning without the 
CV and cvParams that aren't.  I much prefer the latter.  So neither of 
us are arguing for cvParams to go away.  You must be talking to somebody 
else. :)

-Matt

Angel Pizarro wrote:
> 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