psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] Changes to PSIMS CV

[Kallhardt M. <Mar...@bd...>]

Hello from Bremen,

 

I have some changes for the psi-ms.obo, is it OK if sent an attachment
to the whole mailing list or should I sent it to a specific email
address?

It is mainly new terms for Bruker Daltonics instruments and some [is_a]
relationship changes ("subgroups" for our instrument series).

 

Another proposal (open for discussion here) is the including of an
"ftms" subgroup - [is_a: MS:1000443 ! mass analyzer type].

This would change [id: MS:1000079,  name: fourier transform ion
cyclotron resonance] to a [is_a: ID:XXXXXXX ! ftms].

Then we'd like to add [id: ID:XXXXXXX, name: quadrupole fourier
transform ion cyclotron resonance, is_a: ID:XXXXXXX ! ftms] (for our
FTMSs).

 

Best Regards,

i.A. Marius Kallhardt

 

Software Developer

Bruker Daltonik GmbH (Bremen)

Phone:  +49 (0) 421 2205 467

Fax:  +49 (0) 421 2205 305

Mail: mar...@bd...

 

Re: [Psidev-ms-dev] PSI-MSS WG call reminder

[Shofstahl, J. <jim...@th...>]

Eric,

I won't be able to attend this morning due to Jury Duty.

Jim Shofstahl

From: Eric Deutsch [mailto:ede...@sy...]
Sent: Monday, July 27, 2009 11:03 PM
To: 'Mass spectrometry standard development'
Cc: 'Eric Deutsch'
Subject: [Psidev-ms-dev] PSI-MSS WG call reminder

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call will be Tuesday 8am PDT:

http://www.timeanddate.com/worldclock/fixedtime.html?day=28&month=7&year=2009&hour=16&min=0&sec=0&p1=136

08:00 San Francisco
11:00 New York
16:00 London
17:00 Geneva

+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
Generic international: +44 2083222500 (UK number)

access code: 297427

Agenda:
1) mzML 1.1.0
- Outstanding items
  - Policy for source directories: finalize and document
  - Use of version attribute
  - proposal to add terms "m/z precision array" and "intensity precision array": def number of significant digits
- Manuscript

----
2) MIAPE-MS revision
- Have revised document to discuss at HUPO

----
3) TraML development
- Updates pending
  - Try splitting "transition predicted from consensus spectrum ion trap" into two terms
  - Do we want to add the mzML sourceFileList section?
  - <evidence> is not pretty
 - Implementations?

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

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

I can't make the call this morning either unfortunately. What I've tried 
to impress is that whatever option we choose, the version attribute or 
the schemaLocation, it can only be a hint, because before you know what 
schema to use there is no concept of attributes being required. Thus, 
whatever option we choose, it would be something that needs to be 
documented in the specification doc. So my recommendation is to not 
remove the version attribute in 1.1.1 but to document that it is 
meaningless and the schemaLocation hint should be present with the 
specified xsd filename. The alternative - forcing the version attribute 
to be a specific version (and presumably documenting that the 
schemaLocation is meaningless?) - seems unnecessarily un-xml-ish.

Thanks,
Matt


Darren Kessner wrote:
> Hi all,
>
> I just realized that I can't make the meeting this morning.
>
> Regarding the version attribute, I still agree with Matt that having
> an extra version attribute is redundant, and therefore unnecessary.
>
> It's not difficult to implement, of course, but I just don't see the
> point -- implementors will either:
> 1) ignore the field, or
> 2) read it, and verify that it matches the name of the xsd filename,
> reporting error if there is a mismatch
>
>
> Darren
>
>   

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Darren K. <da...@pr...>]

Hi all,

I just realized that I can't make the meeting this morning.

Regarding the version attribute, I still agree with Matt that having
an extra version attribute is redundant, and therefore unnecessary.

It's not difficult to implement, of course, but I just don't see the
point -- implementors will either:
1) ignore the field, or
2) read it, and verify that it matches the name of the xsd filename,
reporting error if there is a mismatch


Darren

[Psidev-ms-dev] PSI-MSS WG call reminder

[Eric D. <ede...@sy...>]

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=28
<http://www.timeanddate.com/worldclock/fixedtime.html?day=28&month=7&year=20
09&hour=16&min=0&sec=0&p1=136> &month=7&year=2009&hour=16&min=0&sec=0&p1=136

 

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)

 

access code: 297427

 

Agenda:

1) mzML 1.1.0

- Outstanding items

  - Policy for source directories: finalize and document

  - Use of version attribute

  - proposal to add terms "m/z precision array" and "intensity precision
array": def number of significant digits

- Manuscript

 

----

2) MIAPE-MS revision

- Have revised document to discuss at HUPO

 

----

3) TraML development

- Updates pending

  - Try splitting "transition predicted from consensus spectrum ion trap"
into two terms

  - Do we want to add the mzML sourceFileList section?

  - <evidence> is not pretty

 - Implementations?

 

 

 

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Chris A. <ch...@ma...>]

Matthew Chambers wrote:
> Regardless of whether the application stores the schema locally or not, 
> it's impossible for the parser to know which schema to use if it doesn't 
> look in the file. The only alternative I can think of is file extension 
> and that is not merely unreliable: it can't feasibly give version 
> information. Bottom line is an mzML consuming application cannot know 
> whether to validate with mzML 1.0 or mzML 1.1 without looking in the 
> file. If strict 1.1 parsers could read 1.0 it would be a different 
> matter (the application could always validate with 1.1) but that is not 
> the case here.

Agreed, although it's really only an issue for 1.0 readers at present. 
If you were to say that going forward any backwards compatibility 
breakages require a namespace change then 1.1-only (and future) readers 
wouldn't need to worry about figuring out which schema to use as the XML 
parser would handle it.  Anyway, it's probably a bit late now.

Regards,
Chris

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

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

Regardless of whether the application stores the schema locally or not, 
it's impossible for the parser to know which schema to use if it doesn't 
look in the file. The only alternative I can think of is file extension 
and that is not merely unreliable: it can't feasibly give version 
information. Bottom line is an mzML consuming application cannot know 
whether to validate with mzML 1.0 or mzML 1.1 without looking in the 
file. If strict 1.1 parsers could read 1.0 it would be a different 
matter (the application could always validate with 1.1) but that is not 
the case here.

-Matt


Chris Allen wrote:
> OK, but from an application perspective it is more reliable to override 
> the hints in the document and specify the namespace to XSD location 
> mapping yourself (eg. "setExternalSchemaLocation()" in Xerces) because 
> the application knows where its schema copies are located, and that 
> means it can validate documents even if the schema location hint is 
> missing or refers to a location that is not accessible.
>
> With the above approach, you also have the option of avoiding the 
> two-pass problem providing that you require that each incompatible 
> version of the schema has a unique namespace URI which you can then map 
> to different XSD files.
>
> Regards,
> Chris
>   

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Chris A. <ch...@ma...>]

Matthew Chambers wrote:
> Our version system as I understand it is major.minor.revision. A major 
> or minor change indicates a break in backward compatibility. Thus, 1.0 
> parsers will not be able to read 1.1 files. Strict 1.1 parsers won't be 
> able to read 1.0 files either, but we have tried to avoid making it very 
> hard to support 1.0 from a 1.1 parser.
> 
> The chicken and the egg problem occurs in another place in XML: the 
> encoding. A parser must start reading the file before it can know what 
> encoding it is (e.g. ascii, utf8, utf16, etc.). If it's a truly 
> forward-only stream, that does make things difficult, but dealing with 
> the encoding is much harder than dealing with the schema, so 
> forward-only XML readers probably have a way to deal with the latter if 
> they have a way to deal with the former.

Yep, that's true.  However most XML parsers take care of the encoding 
detection issue behind the scenes (eg. using an internal buffer until 
they see the <?xml?> encoding declaration).  My point was simply that if 
you choose a versioning scheme that will require peering into the file 
first to figure out which schema to use, then readers will have to 
implement some kind of similar dual-parse/buffering mechanism themselves 
which is extra work.

> 
> Like you said, the "schemaLocation" attribute is an optional "hint" - 
> but without a schema, ALL attributes are optional, including the root 
> "version" attribute (not to be confused with the document declaration 
> "version" attribute, another reason not to use it). And the only way to 
> get a schema without the hint from schemaLocation is to get it based on 
> some other hint. Better the official hint than an unofficial one. :)

OK, but from an application perspective it is more reliable to override 
the hints in the document and specify the namespace to XSD location 
mapping yourself (eg. "setExternalSchemaLocation()" in Xerces) because 
the application knows where its schema copies are located, and that 
means it can validate documents even if the schema location hint is 
missing or refers to a location that is not accessible.

With the above approach, you also have the option of avoiding the 
two-pass problem providing that you require that each incompatible 
version of the schema has a unique namespace URI which you can then map 
to different XSD files.

Regards,
Chris

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

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

Our version system as I understand it is major.minor.revision. A major 
or minor change indicates a break in backward compatibility. Thus, 1.0 
parsers will not be able to read 1.1 files. Strict 1.1 parsers won't be 
able to read 1.0 files either, but we have tried to avoid making it very 
hard to support 1.0 from a 1.1 parser.

The chicken and the egg problem occurs in another place in XML: the 
encoding. A parser must start reading the file before it can know what 
encoding it is (e.g. ascii, utf8, utf16, etc.). If it's a truly 
forward-only stream, that does make things difficult, but dealing with 
the encoding is much harder than dealing with the schema, so 
forward-only XML readers probably have a way to deal with the latter if 
they have a way to deal with the former.

Like you said, the "schemaLocation" attribute is an optional "hint" - 
but without a schema, ALL attributes are optional, including the root 
"version" attribute (not to be confused with the document declaration 
"version" attribute, another reason not to use it). And the only way to 
get a schema without the hint from schemaLocation is to get it based on 
some other hint. Better the official hint than an unofficial one. :)

-Matt


Chris Allen wrote:
> Matthew Chambers wrote:
>   
>> As we discussed at least week's call, there's some debate about the 
>> value of having a separate version attribute. There seem to be two sides 
>> to the debate:
>>     
>
> Just out of interest: What's the intention with backwards compatibility 
> policy here?  If there are breaking changes to the schema that render 
> previous instance documents no longer valid, anyone using a validating 
> parser (eg. XercesC, MSXML) will struggle to support reading more than 
> one major version without a namespace change since you can only map each 
> unique namespace URI to one xsd file^^, and that mapping has to be given 
> to the parser _before_ it starts reading the document (chicken and egg). 
>   Relying only on a version attribute in the document or the 
> "schemaLocation" would require a 2-pass approach, which isn't very 
> practical if you're reading the document from a (forward-only) stream.
>
> See also:
> http://209.85.229.132/search?q=cache%3AVyWUtbQUsFAJ%3Awww.xfront.com%2FVersioning.pdf+%22XML+Schema+Versioning+Best+Practices%22&hl=en&gl=uk
>
> ^^ Yes, instance documents can also provide this mapping (via 
> "schemaLocation") but it is only a hint and quite often it's not 
> practical to rely on for an application because it is optional and may 
> point to a schema location that doesn't exist locally (eg. transferring 
> file between platforms) or isn't accessible for some reason.  Usually 
> the application will ship with a copy of the schema that it supports and 
> it will want to use that instead.
>
> btw, if you choose to encode the full version number in the XSD 
> filename, that potentially means the application requires a copy of each 
> and every version it will support.  If the changes are backwards 
> compatible that seems over the top since the newer version will still 
> validate older instance documents.
>
> Regards,
> Chris
>
>   

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Chris A. <ch...@ma...>]

Matthew Chambers wrote:
> As we discussed at least week's call, there's some debate about the 
> value of having a separate version attribute. There seem to be two sides 
> to the debate:

Just out of interest: What's the intention with backwards compatibility 
policy here?  If there are breaking changes to the schema that render 
previous instance documents no longer valid, anyone using a validating 
parser (eg. XercesC, MSXML) will struggle to support reading more than 
one major version without a namespace change since you can only map each 
unique namespace URI to one xsd file^^, and that mapping has to be given 
to the parser _before_ it starts reading the document (chicken and egg). 
  Relying only on a version attribute in the document or the 
"schemaLocation" would require a 2-pass approach, which isn't very 
practical if you're reading the document from a (forward-only) stream.

See also:
http://209.85.229.132/search?q=cache%3AVyWUtbQUsFAJ%3Awww.xfront.com%2FVersioning.pdf+%22XML+Schema+Versioning+Best+Practices%22&hl=en&gl=uk

^^ Yes, instance documents can also provide this mapping (via 
"schemaLocation") but it is only a hint and quite often it's not 
practical to rely on for an application because it is optional and may 
point to a schema location that doesn't exist locally (eg. transferring 
file between platforms) or isn't accessible for some reason.  Usually 
the application will ship with a copy of the schema that it supports and 
it will want to use that instead.

btw, if you choose to encode the full version number in the XSD 
filename, that potentially means the application requires a copy of each 
and every version it will support.  If the changes are backwards 
compatible that seems over the top since the newer version will still 
validate older instance documents.

Regards,
Chris

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

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

I'm voting for #2.

Marc, the W3C definition of "valid XML" does not apply to XML files 
without a specified schema or DTD. And since we don't have a DTD, an 
mzML document cannot be "valid" without a schema specified. Unless 
you're talking about validity according to the mzML specification, which 
is what we're voting on, because right now the specification document 
doesn't mandate a schema or the version attribute.

Consider the following case:
<mzML schemaLocation="http://psi.hupo.org/ms/mzml 
http://psidev.info/files/ms/mzML/xsd/mzML1.0.0.xsd" version="1.1.0" >
According to the W3C, the correct action is to read/validate the file 
according to the mzML1.0.0 schema no matter what any other attribute 
says. That is fundamental to XSD semantics.

What is the correct behavior in the following case where the version 
takes an unconventional form?
<mzML version="v1.1r0" >
Without assuming a schema (which defeats the proposed benefit of having 
a version attribute), the only way we can try to avoid this in the mzML 
standard is to say the version attribute must take a certain form in the 
specification document. And if we must say that, why don't we just say 
that the schemaLocation XSD filename must always take the form 
"mzML1.1.0.xsd"? That way people can cache it locally but users can 
still parse the version easily. And we can get rid of this redundant 
attribute which unnecessarily deviates from XML/XSD conventions.

-Matt


Marc Sturm wrote:
> Hi all,
>
> I vote for keeping the schema attribute and forcing its value with a
> regular expression
>
> My reasons for that choice are:
> - a file is valid and usable without a specified schema location. If
> the version attribute is given, the parser can assess if it can read
> the file and can even validate the file against a cached schema.
> - even if a schema is given in approach 2, it might reference to a
> local schema without the version string in the name.
> => version 1 is the only one that ensures that the version information
> is available.
>
> -Marc
>
>   
>> 1) Asserts that the attribute is not redundant with the schemaLocation
>> because the schemaLocation is "optional" and the version attribute can
>> be "required." Thus, this side proposes to keep the attribute and
>> enforce its value based on the current schema version. Parsers are
>> expected to determine the version from this attribute. This side asserts
>> that the schema can be determined by parsing the version attribute.
>>
>> 2) Asserts that the attribute is redundant with the schemaLocation
>> because we version the schema in the xsd's filename. Although it's true
>> that the schemaLocation is "optional", without a schema to validate
>> against, there is by definition no concept of "optional" and "required"
>> in XML. Without a schema or DTD, the only concept that can be validated
>> is well-formedness.  Thus, this side proposes to deprecate the attribute
>> and make its value officially meaningless, possibly removing the
>> attribute in a future schema revision. Parsers are expected to determine
>> the version by parsing it from the schemaLocation; note that simply
>> parsing a schemaLocation string does not require downloading the schema.
>> This side of the debate asserts that the schemaLocation attribute must
>> be present so that the schema can be known without making assumptions.
>> The only weakness to this approach that I can think of is that someone
>> could produce mzML documents with different schemaLocations like:
>> schemaLocation="http://psi.hupo.org/ms/mzml
>> http://mysite.org/xsds/mzML/1.1.0/mzML.xsd".
>>
>> We can prevent that in the documentation by mandating that the
>> schemaLocation take the "standard" format:
>> schemaLocation="http://psi.hupo.org/ms/mzml
>> http://psidev.info/files/ms/mzML/xsd/mzML1.1.0.xsd"
>>
>> So in my analysis it comes down to two choices: either we require the
>> version attribute to take a certain form in the standard specification
>> document, or we require the schemaLocation attribute to take a certain
>> form in the standard specification document. In either case, it doesn't
>> make sense to put this requirement into the schema itself.
>>
>> -Matt
>>     
>

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Steffen N. <sne...@ip...>]

On Tue, 2009-07-21 at 06:25 +0200, Marc Sturm wrote:
> I vote for keeping the schema attribute and forcing its value with a
> regular expression
I fully agree with Marc (and others) here.

Yours,
Steffen

Re: [Psidev-ms-dev] Vote on the fate of the version attribute

[Marc S. <st...@in...>]

Hi all,

I vote for keeping the schema attribute and forcing its value with a
regular expression

My reasons for that choice are:
- a file is valid and usable without a specified schema location. If
the version attribute is given, the parser can assess if it can read
the file and can even validate the file against a cached schema.
- even if a schema is given in approach 2, it might reference to a
local schema without the version string in the name.
=> version 1 is the only one that ensures that the version information
is available.

-Marc

> 1) Asserts that the attribute is not redundant with the schemaLocation
> because the schemaLocation is "optional" and the version attribute can
> be "required." Thus, this side proposes to keep the attribute and
> enforce its value based on the current schema version. Parsers are
> expected to determine the version from this attribute. This side asserts
> that the schema can be determined by parsing the version attribute.
>
> 2) Asserts that the attribute is redundant with the schemaLocation
> because we version the schema in the xsd's filename. Although it's true
> that the schemaLocation is "optional", without a schema to validate
> against, there is by definition no concept of "optional" and "required"
> in XML. Without a schema or DTD, the only concept that can be validated
> is well-formedness.  Thus, this side proposes to deprecate the attribute
> and make its value officially meaningless, possibly removing the
> attribute in a future schema revision. Parsers are expected to determine
> the version by parsing it from the schemaLocation; note that simply
> parsing a schemaLocation string does not require downloading the schema.
> This side of the debate asserts that the schemaLocation attribute must
> be present so that the schema can be known without making assumptions.
> The only weakness to this approach that I can think of is that someone
> could produce mzML documents with different schemaLocations like:
> schemaLocation="http://psi.hupo.org/ms/mzml
> http://mysite.org/xsds/mzML/1.1.0/mzML.xsd".
>
> We can prevent that in the documentation by mandating that the
> schemaLocation take the "standard" format:
> schemaLocation="http://psi.hupo.org/ms/mzml
> http://psidev.info/files/ms/mzML/xsd/mzML1.1.0.xsd"
>
> So in my analysis it comes down to two choices: either we require the
> version attribute to take a certain form in the standard specification
> document, or we require the schemaLocation attribute to take a certain
> form in the standard specification document. In either case, it doesn't
> make sense to put this requirement into the schema itself.
>
> -Matt
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

[Psidev-ms-dev] PSI-MSS WG call deferred

[Eric D. <ede...@sy...>]

Hi everyone, let's defer the PSI Mass Spectrometry Standards Working Group
call out another week. There do not seem to be enough agenda items to
warrant a call at this time.

 

Please do weigh in by email on the version/schemaLocation issue posted by
Matt. We were evenly split at the last call and need more voices in the
discussion.

 

Let's talk again in a week.

 

Regards,

Eric

 

 

[Psidev-ms-dev] Vote on the fate of the version attribute

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

Hi all,

As we discussed at least week's call, there's some debate about the 
value of having a separate version attribute. There seem to be two sides 
to the debate:

1) Asserts that the attribute is not redundant with the schemaLocation 
because the schemaLocation is "optional" and the version attribute can 
be "required." Thus, this side proposes to keep the attribute and 
enforce its value based on the current schema version. Parsers are 
expected to determine the version from this attribute. This side asserts 
that the schema can be determined by parsing the version attribute.

2) Asserts that the attribute is redundant with the schemaLocation 
because we version the schema in the xsd's filename. Although it's true 
that the schemaLocation is "optional", without a schema to validate 
against, there is by definition no concept of "optional" and "required" 
in XML. Without a schema or DTD, the only concept that can be validated 
is well-formedness.  Thus, this side proposes to deprecate the attribute 
and make its value officially meaningless, possibly removing the 
attribute in a future schema revision. Parsers are expected to determine 
the version by parsing it from the schemaLocation; note that simply 
parsing a schemaLocation string does not require downloading the schema. 
This side of the debate asserts that the schemaLocation attribute must 
be present so that the schema can be known without making assumptions. 
The only weakness to this approach that I can think of is that someone 
could produce mzML documents with different schemaLocations like:
schemaLocation="http://psi.hupo.org/ms/mzml 
http://mysite.org/xsds/mzML/1.1.0/mzML.xsd".

We can prevent that in the documentation by mandating that the 
schemaLocation take the "standard" format:
schemaLocation="http://psi.hupo.org/ms/mzml 
http://psidev.info/files/ms/mzML/xsd/mzML1.1.0.xsd"

So in my analysis it comes down to two choices: either we require the 
version attribute to take a certain form in the standard specification 
document, or we require the schemaLocation attribute to take a certain 
form in the standard specification document. In either case, it doesn't 
make sense to put this requirement into the schema itself.

-Matt

[Psidev-ms-dev] PSI-MSS WG call notes

[Eric D. <ede...@sy...>]

Hi everyone, here are the notes from today's call

 

Present: Matt, Marc, Jim, Darren, Eric

 

1) mzML 1.1.0

- Outstanding items

- Policy for source directories: finalize and document

+ The policy will be that all of the files needed to encode of the spectra
will be listed. Individual implementations should know what files to
include. If this cannot easily be determined, it would not be harmful to
include all files in the subdir, perhaps after filtering out obvious
contaminating files such as mzData and MGF files that may have been
introduced.

  - Absorbance unit

  + This has been added to the unit ontology

  - proposal to add terms "m/z precision array" and "intensity precision
array": def number of significant digits

  + Eric will write the proposal and send it out for comment

- version attribute discussion

+ There appear to be two proposals: 1) require the version number attribute
and control the values they can take on; 2) let the version attribute
atrophy and make it policy to get the version from the schemaLocation
attribute. The attendees were evenly split on which approach to take. Eric
will email the proposals in a new thread and we would vote.

- Manuscript

+ The manuscript has been submitted to NBT and how we wait.

- AniML

+ Eric attended the last AnIML phone conference and described mzML and our
controlled vocabulary. AnIML is moving forward and includes many data types
beyond mass spec. As they develop mass spec support, they will be looking
closely at mzML.

 

----

2) MIAPE-MS revision

- What is the state of MIAPE-MS and the preparation for the journals meeting
at world HUPO?

 

----

3) TraML development

- Updates pending

  - Try splitting "transition predicted from consensus spectrum ion trap"
into two terms

  - Do we want to add the mzML sourceFileList section?

  - <evidence> is not pretty

 - Implementations?

+ Eric will send out the next revision soon

 

 

 

 

  _____  

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: Monday, July 13, 2009 11:52 PM
To: 'Mass spectrometry standard development'
Cc: 'Eric Deutsch'
Subject: PSI-MSS WG call reminder

 

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=14
<http://www.timeanddate.com/worldclock/fixedtime.html?day=14&month=7&year=20
09&hour=16&min=0&sec=0&p1=136> &month=7&year=2009&hour=16&min=0&sec=0&p1=136

 

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)

 

access code: 297427

 

Agenda:

1) mzML 1.1.0

- Outstanding items

  - Policy for source directories: finalize and document

  - Absorbance unit

  - proposal to add terms "m/z precision array" and "intensity precision
array": def number of significant digits

  - 

- Manuscript

- AniML

 

----

2) MIAPE-MS revision

- Have revised document to discuss at ASMS

 

----

3) TraML development

- Updates pending

  - Try splitting "transition predicted from consensus spectrum ion trap"
into two terms

  - Do we want to add the mzML sourceFileList section?

  - <evidence> is not pretty

  - 

 - Implementations?

 

 

 

[Psidev-ms-dev] PSI-MSS WG call reminder

[Eric D. <ede...@sy...>]

Hi everyone, the next PSI Mass Spectrometry Standards Working Group call
will be Tuesday 8am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=14
<http://www.timeanddate.com/worldclock/fixedtime.html?day=14&month=7&year=20
09&hour=16&min=0&sec=0&p1=136> &month=7&year=2009&hour=16&min=0&sec=0&p1=136

 

08:00 San Francisco

11:00 New York

16:00 London

17:00 Geneva

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)

 

access code: 297427

 

Agenda:

1) mzML 1.1.0

- Outstanding items

  - Policy for source directories: finalize and document

  - Absorbance unit

  - proposal to add terms "m/z precision array" and "intensity precision
array": def number of significant digits

  - 

- Manuscript

- AniML

 

----

2) MIAPE-MS revision

- Have revised document to discuss at ASMS

 

----

3) TraML development

- Updates pending

  - Try splitting "transition predicted from consensus spectrum ion trap"
into two terms

  - Do we want to add the mzML sourceFileList section?

  - <evidence> is not pretty

  - 

 - Implementations?

 

 

 

Re: [Psidev-ms-dev] Agilent MassHunter nativeID format and source type for directory-based formats

[Eric D. <ede...@sy...>]

Hi Matt, this is indeed delightful.

I think the unofficial policy has been to just include them all. If the
converter can tell which ones are really the source, then I'm fine with just
including a subset, but otherwise there seems like only minimal harm in just
listing them all.

Shall we set that down in the spec as the official policy?

Regards,
Eric



> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Wednesday, July 01, 2009 1:14 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Agilent MassHunter nativeID format and source
> type for directory-based formats
> 
> Lest any of you think I was joking about how messy these directory-based
> sources can be, look at these delightful examples:
> 
>  Directory of \bsalgconcc12_1-A,3_01_692.d
> 10/02/2008  03:07 PM    <DIR>
> 080519_lgpepadducts_ms3_flowramp_4_mam_692.m
> 07/28/2008  12:28 PM               223
> 893f91d9-b133-4529-af43-6da496be4766_1.mcf
> 07/28/2008  12:28 PM            15,360
> 893f91d9-b133-4529-af43-6da496be4766_1.mcf_idx
> 06/16/2008  02:24 PM             4,175 Analysis.0.DataAnalysis.method
> 06/16/2008  02:24 PM           314,142 Analysis.0.result_c
> 07/28/2008  12:28 PM             4,562 Analysis.1.DataAnalysis.method
> 07/28/2008  12:28 PM           408,878 Analysis.1.result_c
> 07/29/2008  03:04 PM             4,175 Analysis.2.DataAnalysis.method
> 07/29/2008  03:04 PM           349,561 Analysis.2.result_c
> 07/29/2008  03:04 PM               282 Analysis.content
> 05/20/2008  08:35 AM        51,221,174 Analysis.mzData
> 05/20/2008  08:36 AM             1,197 ANALYSIS.MZXML
> 05/19/2008  04:47 PM        39,906,451 Analysis.yep
> 07/25/2008  01:36 PM                44 BackgroundLineNeg.ami
> 07/25/2008  01:36 PM           424,040 BackgroundLinePos.ami
> 07/25/2008  01:36 PM                44 BackgroundProfNeg.ami
> 07/25/2008  01:36 PM                44 BackgroundProfPos.ami
> 05/19/2008  03:27 PM               502 bsalgconcc12_1-A,3_01_692.hdx
> 05/19/2008  04:47 PM           226,000 bsalgconcc12_1-A,3_01_692.unt
> 07/28/2008  12:28 PM               486 Calibrator.ami
> 01/18/2008  02:26 PM             4,781 CapLCMSRC.hss
> 05/20/2008  08:36 AM               624 CompassXport.log
> 07/25/2008  01:36 PM                57 DensViewNeg.ami
> 07/25/2008  01:36 PM                57 DensViewNegBgnd.ami
> 07/25/2008  01:36 PM        85,283,161 DensViewPos.ami
> 07/25/2008  01:36 PM        48,824,297 DensViewPosBgnd.ami
> 07/29/2008  03:04 PM               127 desktop.ini
> 05/19/2008  04:47 PM           909,020 extension.baf
> 04/10/2007  10:09 AM             1,394 HS_columns.xmc
> 05/19/2008  04:47 PM             3,675 LCParms.txt
> 05/19/2008  04:47 PM               222 NuGenesisTemplate.txt
> 05/19/2008  04:47 PM             1,303 SampleInfo.xml
> 07/28/2008  12:28 PM            24,576 Storage.mcf_idx
> 07/25/2008  01:36 PM                 0 SyncHelper
>               33 File(s)    227,934,634 bytes
>                3 Dir(s)  20,683,268,096 bytes free
> 
> 
>  Directory of \10 fm bsa_1-A,1_01_76.d
> 10/02/2008  03:08 PM    <DIR>          071022_caplc_76.m
> 10/23/2007  09:25 AM               494 10 fm bsa_1-A,1_01_76.hdx
> 10/23/2007  10:41 AM           203,544 10 fm bsa_1-A,1_01_76.unt
> 08/27/2008  03:03 PM        48,697,601
> 91f8a826-2331-44ae-b684-017143b1a8df_1.mcf
> 08/27/2008  03:03 PM            99,328
> 91f8a826-2331-44ae-b684-017143b1a8df_1.mcf_idx
> 06/10/2008  10:20 AM             4,387 Analysis.0.DataAnalysis.method
> 06/10/2008  10:20 AM        16,805,076 Analysis.0.result_c
> 06/17/2008  10:22 AM             4,387 Analysis.1.DataAnalysis.method
> 06/17/2008  10:22 AM        16,827,442 Analysis.1.result_c
> 06/20/2008  03:53 PM             2,750 Analysis.2.DataAnalysis.method
> 06/20/2008  03:53 PM        16,818,436 Analysis.2.result_c
> 08/27/2008  03:03 PM             3,137 Analysis.3.DataAnalysis.method
> 08/27/2008  03:03 PM           496,255 Analysis.3.result_c
> 08/27/2008  03:03 PM               370 Analysis.content
> 06/09/2008  05:15 PM           213,982 Analysis.ETD.mgf
> 06/09/2008  05:15 PM             1,094 Analysis.mgf
> 10/25/2007  10:25 AM        17,805,450 Analysis.mzData
> 06/09/2008  04:01 PM        65,489,623 ANALYSIS.MZXML
> 10/23/2007  10:41 AM        38,598,852 Analysis.yep
> 08/22/2008  01:09 PM            25,288 BackgroundLineNeg.ami
> 08/22/2008  01:08 PM           341,776 BackgroundLinePos.ami
> 08/22/2008  01:09 PM            84,088 BackgroundProfNeg.ami
> 08/22/2008  01:09 PM           279,280 BackgroundProfPos.ami
> 06/18/2008  12:38 PM             2,652 BSA76_cmpd168_mH527_3_.mgf
> 08/26/2008  02:15 PM             2,462 bsa_etd_76_mgf_mz_722.mgf
> 08/26/2008  02:45 PM             2,081 bsa_etd_76_mgf_mz_722_no_decon.mgf
> 08/27/2008  03:03 PM               486 Calibrator.ami
> 10/17/2007  04:06 PM             4,513 CapLCMSRC.hss
> 06/09/2008  04:01 PM           235,481 CompassXport.log
> 08/22/2008  01:08 PM           927,585 DensViewNeg.ami
> 08/22/2008  01:14 PM           220,777 DensViewNegBgnd.ami
> 08/22/2008  01:08 PM        29,456,201 DensViewPos.ami
> 08/22/2008  01:09 PM        26,476,073 DensViewPosBgnd.ami
> 08/27/2008  03:03 PM               125 desktop.ini
> 10/23/2007  10:41 AM           675,228 extension.baf
> 10/23/2007  10:26 AM           291,978 file 76.ETD.mgf
> 10/23/2007  10:26 AM             1,139 file 76.mgf
> 10/23/2007  10:34 AM           291,978 file 76mod.ETD.mgf
> 04/10/2007  10:09 AM             1,394 HS_columns.xmc
> 10/23/2007  10:41 AM             3,052 LCParms.txt
> 10/02/2008  03:08 PM    <DIR>          Mascot Results
> 10/23/2007  10:41 AM               219 NuGenesisTemplate.txt
> 10/02/2008  03:08 PM    <DIR>          Ommsa etd search results
> 06/09/2008  05:15 PM                 0 ProteinDataBaseQuery.mct
> 06/09/2008  05:15 PM             1,080 ProteinDataBaseQuery.MGF
> 10/23/2007  10:41 AM             1,176 SampleInfo.xml
> 08/27/2008  03:03 PM            24,576 Storage.mcf_idx
> 08/22/2008  01:08 PM                 0 SyncHelper
>               45 File(s)    281,422,896 bytes
>                5 Dir(s)  20,682,661,888 bytes free
> 
> 
>  Directory of \D7_band4_mlm9_44_1-F,7_01_119.d
> 12/06/2007  03:25 AM               529  D7_band4_mlm9_44_1-F,7_01_119.hdx
> 12/06/2007  04:41 AM           220,120  D7_band4_mlm9_44_1-F,7_01_119.unt
> 10/02/2008  02:52 PM    <DIR>          071119_caplc_lo_thres_119.m
> 12/10/2007  06:58 PM             4,175 Analysis.0.DataAnalysis.method
> 12/10/2007  06:58 PM           480,225 Analysis.0.result_c
> 12/21/2007  05:10 PM             4,175 Analysis.1.DataAnalysis.method
> 12/21/2007  05:10 PM           480,213 Analysis.1.result_c
> 12/21/2007  05:10 PM               190 Analysis.content
> 12/10/2007  12:49 PM        50,823,424 Analysis.mzData
> 12/06/2007  04:41 AM       105,680,964 Analysis.yep
> 10/17/2007  04:06 PM             4,513 CapLCMSRC.hss
> 12/21/2007  05:10 PM               131 desktop.ini
> 12/06/2007  04:41 AM           902,936 extension.baf
> 04/10/2007  10:09 AM             1,394 HS_columns.xmc
> 12/06/2007  04:41 AM             3,072 LCParms.txt
> 12/06/2007  04:41 AM               227 NuGenesisTemplate.txt
> 12/06/2007  04:41 AM             1,265 SampleInfo.xml
>               16 File(s)    158,607,553 bytes
>                3 Dir(s)  20,684,148,736 bytes free
> 
> So...any input about what files we should include in the sourceFileList?
> 
> -Matt
> 
> 
> Matthew Chambers wrote:
> > Hi all,
> >
> > We need terms for Agilent MassHunter sources in the CV. In the
> > MassHunter API there are two ways to uniquely address a spectrum: by
> > "row number" or "scan id". Row number is essentially a 0-based index
> > that refers to the spectra after the acquisition software has done
> > something...perhaps internal merging? Scan id represents the ordinal
> > number of acquisitions as they come off the instrument. So, at least on
> > their (Q)TOF instruments, the rowNumber is very disparate from the
> > scanId, but both of them are unique identifiers that can technically be
> > used to refer to a native spectrum. The kink is that the MassHunter API
> > only refers to the parent scan by its scan id and doesn't provide a way
> > to directly translate a scan id to a row number - translation must be
> > done indirectly by enumerating all the row numbers and building a
> > mapping of scan id to row number. For this reason I would recommend that
> > the nativeID format be defined as "scanId=xsd:nonNegativeInteger" but
> > I'm open to comment on this!
> >
> > The source type brings another issue to a head. We actually have more
> > vendor formats that use directories to store their raw data than those
> > that use files.
> > Directories: Agilent MassHunter (read with MHDAC API), Bruker/Agilent
> > YEP, Bruker BAF, Bruker FID, Bruker U2 (previous 4 formats read with
> > CompassXtract API), Waters MassLynx (read with DACServer API)
> > Files: ABI WIFF (read with either Analyst or WiffFileDataReader APIs),
> > Thermo RAW (read with XRawfile API)
> >
> > But we don't clearly define how to deal with the directory-based
> > formats. I'm tempted to recommend that we include and checksum all files
> > within the directories, but it's entirely possible that some people
> > store alternative encodings of the data inside these directories, e.g.
> > mzXML and MGF (I've seen this). So it would be silly to include mzXML
> > and MGF as source files for the native data. There can also be analyses
> > of the data stored there, like Bruker and Agilent's *.m subdirectories,
> > or even pepXML files. Is it reasonable to determine which files in these
> > sources are used by the APIs and put that information in the CV
> > definition for the source types - possibly in a machine-readable way?
> > Also, if we're not going to (and I wouldn't want to) define a separate
> > source type for each subfile (see attached thread ending on 2009-19-03),
> > we would have to document somewhere that every file that should be
> > included in these directory-based formats should be given the
> > directory-level CV term as its source type.
> >
> > -Matt
> >
> >
> >
> >> Matthew Chambers wrote:
> >>
> >>
> >>>> Yes, I made that change, but I forgot that every sourceFile has to
> have
> >>>> a type. That does make it ugly. I was trying to make things
> consistent
> >>>> between Waters and Bruker formats because they both use directories,
> but
> >>>> perhaps I should have gone the other direction and made the source
> type
> >>>> for Bruker directories more applicable to the format as a whole - the
> >>>> problem is I'm not knowledgeable about those formats to know what
> each
> >>>> one corresponds to that is analogous to MassLynx. In any case, I
> don't
> >>>> think the meaning of the term changed. The important part is that
> it's
> >>>> the MassLynx format, not whether it's called DAT or RAW.
> >>>>
> >>>> -Matt
> >>>>
> >>>>
> >>>> Fredrik Levander wrote:
> >>>>
> >>>>
> >>>
> >>>
> >>>>>> Just noticed that the name and definition of MS:1000526 MassLynx
> raw
> >>>>>> format has changed to Waters DAT format. Is this really wanted? I
> guess
> >>>>>> that one would like to have all files in a MassLynx raw folder as
> source
> >>>>>> files, since they will all contain some information that is used in
> the
> >>>>>> mzML file, and then they are all part of the the same source file
> format
> >>>>>> (in my opinion). Or otherwise there will be need to add an
> _FUNCTNS.INF
> >>>>>> file format and a header.txt format, etc.
> >>>>>> If there is need for separate file formats for these sub-files, I
> think
> >>>>>> those terms (including the DAT one) should have new accession
> numbers,
> >>>>>> since the meaning of the term has changed, or am I interpreting
> this in
> >>>>>> the wrong way?
> >>>>>>
> >>>>>> Fredrik
> >>>>>>
> 
> --------------------------------------------------------------------------
> ----
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] MzML version

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

Major.Minor.Revision. I thought we decided that changes to the minor 
version would break compatibility? So "1\.1\.\d+" would be justifiably 
more strict? However, I suspect this WILL break compatibility with files 
produced by 1.1.0 writers that have not been writing a version at all or 
writing it in a different format like "mzML 1.1.0". I know we haven't 
been doing it in pwiz. I never noticed it because I don't use word-wrap 
very much when looking at XML and the attribute was off the screen.

-Matt


Marc Sturm wrote:
> Good point. The regexp "1\.\d+\.\d+" seems fine to me.
> -Marc
>
> Fredrik Levander wrote:
>   
>> My argument for the regexp is that if a parser is using the 1.1.0 schema 
>> and runs into a 1.1.1 file, it shouldn't break by default. The rest of 
>> the document would be validated anyway, and if it conformed to the 1.1.0 
>> schema it is fine. A validating 1.1.0 parser would break with a 1.0.0 
>> file because of the other schema changes anyway, but if there is just a 
>> minor addition to the schema which affects 1% of files, it should pass 
>> validation, but the version number is flagged to the parser which could 
>> react in someway.
>>
>> Regards
>>
>> Fredrik
>>
>> Marc Sturm wrote:
>>   
>>     
>>> Hi,
>>>
>>> when we release version 1.1.1, the string "1.1.1" would have to be added 
>>> to the version enum.
>>> Thus, validating parsers would have no problem with this approach.
>>>
>>> A regexp like "1\.\d+\.\d+" would more flexible, but we all know that 
>>> flexibility is not always desirable :)
>>> I think "1.9.9" should not validate, because there is no such version...
>>>
>>> Best,
>>>   Marc
>>>
>>> Fredrik Levander wrote:
>>>   
>>>     
>>>       
>>>> Question is whether a validating parser should break or not here. The 
>>>> decision for the namespace was to keep it version neutral, allowing 
>>>> reading of different versions with the same parser. If it is enforced to 
>>>> "1.1.0" only, that means parsers would stop there if the number was 
>>>> different. If someone is producing a 1.1.1 file, which conforms to 
>>>> 1.1.0, except for the version, I think it would be up to the version 
>>>> 1.1.0 parser to decide what to do with it. Therefore regexp (something 
>>>> like "1\.\d+\.\d+" ) is what I'd vote for.
>>>>
>>>> Fredrik
>>>>
>>>> Marc Sturm wrote:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> I vote for forcing the version to "1.0.0" or "1.1.0" using an enum. Like 
>>>>> that we can validate that a correct version is used.
>>>>>
>>>>> -Marc
>>>>>
>>>>> Angel Pizarro wrote:
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>>>> I don't know. Seems like double data entry to me, or a code smell held 
>>>>>> over from the ramp days of XML parsing by line.
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers 
>>>>>> <mat...@va... 
>>>>>> <mailto:mat...@va...>> wrote:
>>>>>>
>>>>>>     I concur. This should be given a forced value in the schema equal
>>>>>>     to the
>>>>>>     schema's version. I think we have a chance to use our revision number
>>>>>>     which indicates the new schema version will cause no problems with
>>>>>>     backward compatibility (unless of course you wrote the wrong version,
>>>>>>     which is the whole point of the revision).
>>>>>>
>>>>>>     -Matt
>>>>>>
>>>>>>
>>>>>>     Marc Sturm wrote:
>>>>>>     > Hi all,
>>>>>>     >
>>>>>>     > we just noticed that the 'version' attribute of the 'mzML'
>>>>>>     element is
>>>>>>     > mandatory but can be left empty. We should either force a correct
>>>>>>     > version it with a regular expression, with an enum, or at least
>>>>>>     set the
>>>>>>     > minimum length to 5. Any opinions?
>>>>>>     >
>>>>>>     > -Marc
>>>>>>             
>

Re: [Psidev-ms-dev] MzML version

[Marc S. <st...@in...>]

Good point. The regexp "1\.\d+\.\d+" seems fine to me.
-Marc

Fredrik Levander wrote:
> My argument for the regexp is that if a parser is using the 1.1.0 schema 
> and runs into a 1.1.1 file, it shouldn't break by default. The rest of 
> the document would be validated anyway, and if it conformed to the 1.1.0 
> schema it is fine. A validating 1.1.0 parser would break with a 1.0.0 
> file because of the other schema changes anyway, but if there is just a 
> minor addition to the schema which affects 1% of files, it should pass 
> validation, but the version number is flagged to the parser which could 
> react in someway.
>
> Regards
>
> Fredrik
>
> Marc Sturm wrote:
>   
>> Hi,
>>
>> when we release version 1.1.1, the string "1.1.1" would have to be added 
>> to the version enum.
>> Thus, validating parsers would have no problem with this approach.
>>
>> A regexp like "1\.\d+\.\d+" would more flexible, but we all know that 
>> flexibility is not always desirable :)
>> I think "1.9.9" should not validate, because there is no such version...
>>
>> Best,
>>   Marc
>>
>> Fredrik Levander wrote:
>>   
>>     
>>> Question is whether a validating parser should break or not here. The 
>>> decision for the namespace was to keep it version neutral, allowing 
>>> reading of different versions with the same parser. If it is enforced to 
>>> "1.1.0" only, that means parsers would stop there if the number was 
>>> different. If someone is producing a 1.1.1 file, which conforms to 
>>> 1.1.0, except for the version, I think it would be up to the version 
>>> 1.1.0 parser to decide what to do with it. Therefore regexp (something 
>>> like "1\.\d+\.\d+" ) is what I'd vote for.
>>>
>>> Fredrik
>>>
>>> Marc Sturm wrote:
>>>   
>>>     
>>>       
>>>> I vote for forcing the version to "1.0.0" or "1.1.0" using an enum. Like 
>>>> that we can validate that a correct version is used.
>>>>
>>>> -Marc
>>>>
>>>> Angel Pizarro wrote:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> I don't know. Seems like double data entry to me, or a code smell held 
>>>>> over from the ramp days of XML parsing by line.
>>>>>
>>>>>
>>>>> On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers 
>>>>> <mat...@va... 
>>>>> <mailto:mat...@va...>> wrote:
>>>>>
>>>>>     I concur. This should be given a forced value in the schema equal
>>>>>     to the
>>>>>     schema's version. I think we have a chance to use our revision number
>>>>>     which indicates the new schema version will cause no problems with
>>>>>     backward compatibility (unless of course you wrote the wrong version,
>>>>>     which is the whole point of the revision).
>>>>>
>>>>>     -Matt
>>>>>
>>>>>
>>>>>     Marc Sturm wrote:
>>>>>     > Hi all,
>>>>>     >
>>>>>     > we just noticed that the 'version' attribute of the 'mzML'
>>>>>     element is
>>>>>     > mandatory but can be left empty. We should either force a correct
>>>>>     > version it with a regular expression, with an enum, or at least
>>>>>     set the
>>>>>     > minimum length to 5. Any opinions?
>>>>>     >
>>>>>     > -Marc
>>>>>
>>>>>     ------------------------------------------------------------------------------
>>>>>     Enter the BlackBerry Developer Challenge
>>>>>     This is your chance to win up to $100,000 in prizes! For a limited
>>>>>     time,
>>>>>     vendors submitting new applications to BlackBerry App World(TM)
>>>>>     will have
>>>>>     the opportunity to enter the BlackBerry Developer Challenge. See
>>>>>     full prize
>>>>>     details at: http://p.sf.net/sfu/Challenge
>>>>>     _______________________________________________
>>>>>     Psidev-ms-dev mailing list
>>>>>     Psi...@li...
>>>>>     <mailto:Psi...@li...>
>>>>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Angel Pizarro
>>>>> Director, ITMAT Bioinformatics Facility
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Enter the BlackBerry Developer Challenge  
>>>>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>>>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>>>>> details at: http://p.sf.net/sfu/Challenge
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Psidev-ms-dev mailing list
>>>>> Psi...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> ------------------------------------------------------------------------------
>>>> Enter the BlackBerry Developer Challenge  
>>>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>>>> details at: http://p.sf.net/sfu/Challenge
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>   
>>>>     
>>>>       
>>>>         
>>> ------------------------------------------------------------------------------
>>> Enter the BlackBerry Developer Challenge  
>>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>>> details at: http://p.sf.net/sfu/Challenge
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>   
>>>     
>>>       
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge  
>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] MzML version

[Fredrik L. <Fre...@im...>]

My argument for the regexp is that if a parser is using the 1.1.0 schema 
and runs into a 1.1.1 file, it shouldn't break by default. The rest of 
the document would be validated anyway, and if it conformed to the 1.1.0 
schema it is fine. A validating 1.1.0 parser would break with a 1.0.0 
file because of the other schema changes anyway, but if there is just a 
minor addition to the schema which affects 1% of files, it should pass 
validation, but the version number is flagged to the parser which could 
react in someway.

Regards

Fredrik

Marc Sturm wrote:
> Hi,
>
> when we release version 1.1.1, the string "1.1.1" would have to be added 
> to the version enum.
> Thus, validating parsers would have no problem with this approach.
>
> A regexp like "1\.\d+\.\d+" would more flexible, but we all know that 
> flexibility is not always desirable :)
> I think "1.9.9" should not validate, because there is no such version...
>
> Best,
>   Marc
>
> Fredrik Levander wrote:
>   
>> Question is whether a validating parser should break or not here. The 
>> decision for the namespace was to keep it version neutral, allowing 
>> reading of different versions with the same parser. If it is enforced to 
>> "1.1.0" only, that means parsers would stop there if the number was 
>> different. If someone is producing a 1.1.1 file, which conforms to 
>> 1.1.0, except for the version, I think it would be up to the version 
>> 1.1.0 parser to decide what to do with it. Therefore regexp (something 
>> like "1\.\d+\.\d+" ) is what I'd vote for.
>>
>> Fredrik
>>
>> Marc Sturm wrote:
>>   
>>     
>>> I vote for forcing the version to "1.0.0" or "1.1.0" using an enum. Like 
>>> that we can validate that a correct version is used.
>>>
>>> -Marc
>>>
>>> Angel Pizarro wrote:
>>>   
>>>     
>>>       
>>>> I don't know. Seems like double data entry to me, or a code smell held 
>>>> over from the ramp days of XML parsing by line.
>>>>
>>>>
>>>> On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers 
>>>> <mat...@va... 
>>>> <mailto:mat...@va...>> wrote:
>>>>
>>>>     I concur. This should be given a forced value in the schema equal
>>>>     to the
>>>>     schema's version. I think we have a chance to use our revision number
>>>>     which indicates the new schema version will cause no problems with
>>>>     backward compatibility (unless of course you wrote the wrong version,
>>>>     which is the whole point of the revision).
>>>>
>>>>     -Matt
>>>>
>>>>
>>>>     Marc Sturm wrote:
>>>>     > Hi all,
>>>>     >
>>>>     > we just noticed that the 'version' attribute of the 'mzML'
>>>>     element is
>>>>     > mandatory but can be left empty. We should either force a correct
>>>>     > version it with a regular expression, with an enum, or at least
>>>>     set the
>>>>     > minimum length to 5. Any opinions?
>>>>     >
>>>>     > -Marc
>>>>
>>>>     ------------------------------------------------------------------------------
>>>>     Enter the BlackBerry Developer Challenge
>>>>     This is your chance to win up to $100,000 in prizes! For a limited
>>>>     time,
>>>>     vendors submitting new applications to BlackBerry App World(TM)
>>>>     will have
>>>>     the opportunity to enter the BlackBerry Developer Challenge. See
>>>>     full prize
>>>>     details at: http://p.sf.net/sfu/Challenge
>>>>     _______________________________________________
>>>>     Psidev-ms-dev mailing list
>>>>     Psi...@li...
>>>>     <mailto:Psi...@li...>
>>>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Angel Pizarro
>>>> Director, ITMAT Bioinformatics Facility
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Enter the BlackBerry Developer Challenge  
>>>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>>>> details at: http://p.sf.net/sfu/Challenge
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>   
>>>>     
>>>>       
>>>>         
>>> ------------------------------------------------------------------------------
>>> Enter the BlackBerry Developer Challenge  
>>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>>> details at: http://p.sf.net/sfu/Challenge
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>   
>>>     
>>>       
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge  
>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] MzML version

[Marc S. <stu...@gm...>]

Hi,

when we release version 1.1.1, the string "1.1.1" would have to be added 
to the version enum.
Thus, validating parsers would have no problem with this approach.

A regexp like "1\.\d+\.\d+" would more flexible, but we all know that 
flexibility is not always desirable :)
I think "1.9.9" should not validate, because there is no such version...

Best,
  Marc

Fredrik Levander wrote:
> Question is whether a validating parser should break or not here. The 
> decision for the namespace was to keep it version neutral, allowing 
> reading of different versions with the same parser. If it is enforced to 
> "1.1.0" only, that means parsers would stop there if the number was 
> different. If someone is producing a 1.1.1 file, which conforms to 
> 1.1.0, except for the version, I think it would be up to the version 
> 1.1.0 parser to decide what to do with it. Therefore regexp (something 
> like "1\.\d+\.\d+" ) is what I'd vote for.
>
> Fredrik
>
> Marc Sturm wrote:
>   
>> I vote for forcing the version to "1.0.0" or "1.1.0" using an enum. Like 
>> that we can validate that a correct version is used.
>>
>> -Marc
>>
>> Angel Pizarro wrote:
>>   
>>     
>>> I don't know. Seems like double data entry to me, or a code smell held 
>>> over from the ramp days of XML parsing by line.
>>>
>>>
>>> On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers 
>>> <mat...@va... 
>>> <mailto:mat...@va...>> wrote:
>>>
>>>     I concur. This should be given a forced value in the schema equal
>>>     to the
>>>     schema's version. I think we have a chance to use our revision number
>>>     which indicates the new schema version will cause no problems with
>>>     backward compatibility (unless of course you wrote the wrong version,
>>>     which is the whole point of the revision).
>>>
>>>     -Matt
>>>
>>>
>>>     Marc Sturm wrote:
>>>     > Hi all,
>>>     >
>>>     > we just noticed that the 'version' attribute of the 'mzML'
>>>     element is
>>>     > mandatory but can be left empty. We should either force a correct
>>>     > version it with a regular expression, with an enum, or at least
>>>     set the
>>>     > minimum length to 5. Any opinions?
>>>     >
>>>     > -Marc
>>>
>>>     ------------------------------------------------------------------------------
>>>     Enter the BlackBerry Developer Challenge
>>>     This is your chance to win up to $100,000 in prizes! For a limited
>>>     time,
>>>     vendors submitting new applications to BlackBerry App World(TM)
>>>     will have
>>>     the opportunity to enter the BlackBerry Developer Challenge. See
>>>     full prize
>>>     details at: http://p.sf.net/sfu/Challenge
>>>     _______________________________________________
>>>     Psidev-ms-dev mailing list
>>>     Psi...@li...
>>>     <mailto:Psi...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>>
>>>
>>>
>>> -- 
>>> Angel Pizarro
>>> Director, ITMAT Bioinformatics Facility
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Enter the BlackBerry Developer Challenge  
>>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>>> details at: http://p.sf.net/sfu/Challenge
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>   
>>>     
>>>       
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge  
>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] MzML version

[Fredrik L. <Fre...@im...>]

Question is whether a validating parser should break or not here. The 
decision for the namespace was to keep it version neutral, allowing 
reading of different versions with the same parser. If it is enforced to 
"1.1.0" only, that means parsers would stop there if the number was 
different. If someone is producing a 1.1.1 file, which conforms to 
1.1.0, except for the version, I think it would be up to the version 
1.1.0 parser to decide what to do with it. Therefore regexp (something 
like "1\.\d+\.\d+" ) is what I'd vote for.

Fredrik

Marc Sturm wrote:
> I vote for forcing the version to "1.0.0" or "1.1.0" using an enum. Like 
> that we can validate that a correct version is used.
>
> -Marc
>
> Angel Pizarro wrote:
>   
>> I don't know. Seems like double data entry to me, or a code smell held 
>> over from the ramp days of XML parsing by line.
>>
>>
>> On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers 
>> <mat...@va... 
>> <mailto:mat...@va...>> wrote:
>>
>>     I concur. This should be given a forced value in the schema equal
>>     to the
>>     schema's version. I think we have a chance to use our revision number
>>     which indicates the new schema version will cause no problems with
>>     backward compatibility (unless of course you wrote the wrong version,
>>     which is the whole point of the revision).
>>
>>     -Matt
>>
>>
>>     Marc Sturm wrote:
>>     > Hi all,
>>     >
>>     > we just noticed that the 'version' attribute of the 'mzML'
>>     element is
>>     > mandatory but can be left empty. We should either force a correct
>>     > version it with a regular expression, with an enum, or at least
>>     set the
>>     > minimum length to 5. Any opinions?
>>     >
>>     > -Marc
>>
>>     ------------------------------------------------------------------------------
>>     Enter the BlackBerry Developer Challenge
>>     This is your chance to win up to $100,000 in prizes! For a limited
>>     time,
>>     vendors submitting new applications to BlackBerry App World(TM)
>>     will have
>>     the opportunity to enter the BlackBerry Developer Challenge. See
>>     full prize
>>     details at: http://p.sf.net/sfu/Challenge
>>     _______________________________________________
>>     Psidev-ms-dev mailing list
>>     Psi...@li...
>>     <mailto:Psi...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>
>>
>>
>> -- 
>> Angel Pizarro
>> Director, ITMAT Bioinformatics Facility
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge  
>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>> details at: http://p.sf.net/sfu/Challenge
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] MzML version

[Marc S. <stu...@gm...>]

I vote for forcing the version to "1.0.0" or "1.1.0" using an enum. Like 
that we can validate that a correct version is used.

-Marc

Angel Pizarro wrote:
> I don't know. Seems like double data entry to me, or a code smell held 
> over from the ramp days of XML parsing by line.
>
>
> On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers 
> <mat...@va... 
> <mailto:mat...@va...>> wrote:
>
>     I concur. This should be given a forced value in the schema equal
>     to the
>     schema's version. I think we have a chance to use our revision number
>     which indicates the new schema version will cause no problems with
>     backward compatibility (unless of course you wrote the wrong version,
>     which is the whole point of the revision).
>
>     -Matt
>
>
>     Marc Sturm wrote:
>     > Hi all,
>     >
>     > we just noticed that the 'version' attribute of the 'mzML'
>     element is
>     > mandatory but can be left empty. We should either force a correct
>     > version it with a regular expression, with an enum, or at least
>     set the
>     > minimum length to 5. Any opinions?
>     >
>     > -Marc
>
>     ------------------------------------------------------------------------------
>     Enter the BlackBerry Developer Challenge
>     This is your chance to win up to $100,000 in prizes! For a limited
>     time,
>     vendors submitting new applications to BlackBerry App World(TM)
>     will have
>     the opportunity to enter the BlackBerry Developer Challenge. See
>     full prize
>     details at: http://p.sf.net/sfu/Challenge
>     _______________________________________________
>     Psidev-ms-dev mailing list
>     Psi...@li...
>     <mailto:Psi...@li...>
>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
>
> -- 
> Angel Pizarro
> Director, ITMAT Bioinformatics Facility
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] MzML version

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

I don't know. Seems like double data entry to me, or a code smell held over
from the ramp days of XML parsing by line.

On Thu, Jul 9, 2009 at 6:50 PM, Matthew Chambers <
mat...@va...> wrote:

> I concur. This should be given a forced value in the schema equal to the
> schema's version. I think we have a chance to use our revision number
> which indicates the new schema version will cause no problems with
> backward compatibility (unless of course you wrote the wrong version,
> which is the whole point of the revision).
>
> -Matt
>
>
> Marc Sturm wrote:
> > Hi all,
> >
> > we just noticed that the 'version' attribute of the 'mzML' element is
> > mandatory but can be left empty. We should either force a correct
> > version it with a regular expression, with an enum, or at least set the
> > minimum length to 5. Any opinions?
> >
> > -Marc
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility