From: Marc S. <stu...@gm...> - 2009-07-08 12:55:17
|
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 |
From: Matthew C. <mat...@va...> - 2009-07-09 22:52:14
|
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 |
From: Angel P. <an...@ma...> - 2009-07-10 00:20:48
|
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 |
From: Marc S. <stu...@gm...> - 2009-07-10 08:14:15
|
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 > |
From: Fredrik L. <Fre...@im...> - 2009-07-10 08:47:11
|
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 > |
From: Marc S. <stu...@gm...> - 2009-07-10 09:18:39
|
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 > |
From: Fredrik L. <Fre...@im...> - 2009-07-10 09:30:45
|
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 > |
From: Marc S. <st...@in...> - 2009-07-10 11:17:35
|
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 > |
From: Matt C. <mat...@va...> - 2009-07-10 12:49:27
|
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 >>>>>> > |