Re: [Psidev-ms-dev] PSI-MSSWG call in 8 hr

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

Hi Michael,

Coleman, Michael wrote:
>>  nativeID="19"
>>  nativeID="2,6,5"
>>  nativeID="run1,3,4"
>>  nativeID=""run1,2",3,4"
>>     
> I don't understand what the meaning would be in these four cases.  The fourth would seem to be
>
>     "run1,2",3,4
>
> Is this just covering a corner case to show that the value of 'nativeID' is a comma-separated list of items, each of which can include commas if quoted?  (and if so, can an item also include a double-quote character?)
>   
Yes, it is covering that case, although I don't know if I would call it 
a corner case. I think strings inside native IDs are moderately likely 
(for example, for IDs from ABI's 4000 series instruments), and they 
might contain commas. Good catch about the double quote character, 
though. We should allow for it, but I don't know how to escape it! 
Perhaps we should URL encode the string components instead of using 
XML-escaped double quotes? So the last example would be:
%22run1%2C2%22,3,4

That looks awful, but otherwise the string "foo" (including the quotes 
as part of the string) would have to be encoded like 
"""foo""" (the implicit rule being that a pair of 
" should be treated as a double-escaped quotation, i.e. it's part 
of the id string instead of delimiting the string itself.


>>  - 0-1 "charge state"
>>  XOR
>>  - 2-N "possible charge state"
>>     
>
> By specifying "2-N", it seems like you're implicitly saying that by declaring that +2 or +3 is "possible" that all other charges are not possible.
>
> The alternative would be to specify "1-N", in which case +1 could mean "I think the charge is +1, but it might be something else".  Unless this interpretation is ruled out, it seems like "1-N" ought to be specified.
>   
I'm not sure if you're confused about the meaning of 2-N in this case or 
if I'm confused about your meaning. The 2-N means the number of elements 
of that type that there can be. If the "possible charge state" element 
is used, there must be at least two proposed possible charge states or 
else it makes no sense to qualify the charge state assessment with the 
word "possible." In any case, if "possible charge state" was 1-N, it 
would be confusing for implementors as to which one to use when they are 
trying to figure out what to write. However, perhaps we should rename 
the term "probable charge state" since technically any charge state is 
possible? :)


>>  Index should be *complete* so it could be used for a list of items to seek to
>>     
>
> Might also specify that it's one-to-one: that is, every index entry must actually point to one spectrum (that is actually present in the file).  Is it specified that the order of the index entries is the same as the order of the spectra in the file?
>   
I think both these things are already specified. If not, I agree that 
they should be.

-Matt