Menu
▾
▴
Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10
|
From: Fredrik L. <Fre...@im...> - 2008-05-05 09:16:24
|
Hi Matt, good point about mzXML referencing. The easy rule would be to have all non-mzML referencing as externalNativeID, but if I get it correctly mzXML both have scan num and native id nowadays (correct me if I am wrong) which could make this confusing? And I guess we'd like to reference the scan num, so maybe mzXML and mzData files (in addition to mzML files) should be referenced by externalSpectrumID, and all other files using externalNativeID? I think the first three classes that you suggest should be enough. If we don't know what the source file is, it seems unlikely that we'd like to reference a specific scan in it. I am not sure whether there is a need for a possibility to add a reference to the nativeID in addition to a spectrumRef (IDREF type). It could be easily retrieved by looking up the spectrum in the same file, so it may be unneccesary. I don't think this is the kind of information that needs very fast lookup. Fredrik 2 maj 2008 kl. 23.40 skrev Matthew Chambers: > Is a native file one that an actual instrument wrote or is it anything > that isn't mzML? I.e. do we use externalNativeID to refer to a scan in > an mzXML file, or do we use externalSpectrumID? Also, I'm willing to > forfeit the possibility of referencing a spectrum within the current > file that is not actually there. > > So I see three possibilities, adding one to Darren's list: > spectrumRef (infer reference as current file and spectrumRef is IDREF > pointing to an existing spectrum's id) > sourceFileRef + externalNativeID (original file is native) > sourceFileRef + externalSpectrumID (original file is mzML) > > A fourth possibility may be useful, but not necessary: > nativeSpectrumRef (infer reference as current file and > nativeSpectrumRef > is string pointing to an existing spectrum's nativeID) > > The three main cases can be schematically validated. Semantic > validation > would not be necessary to ensure that we don't get: > sourceFileRef + spectrumRef or > externalNativeID or > externalSpectrumID or > externalNativeID + externalSpectrumID or > spectrumRef + externalSpectrumID, etc... > > -Matt > > > Darren Kessner wrote: >> Hi Eric, >> >> Thanks for the nice summary. >> >> I agree with Fredrik's proposal to add: >> sourceFileRef + externalNativeID >> since the sourceFileRef may refer to a native data file, so >> externalSpectrumID won't make sense. >> >> I believe Matt's case is covered by the two possibilities: >> sourceFileRef + externalNativeID (original file is native) >> sourceFileRef + externalSpectrumID (original file is mzML) >> >> >> Darren >> >> >> On May 2, 2008, at 12:28 PM, Fredrik Levander wrote: >> >> >>> Hi Eric and others, >>> >>> All nice thoughts and proposals. I would also add an example 4 which >>> is: >>> >>> Example 4: (the current spectrum is a sum of two scans which had >>> nativeIDs func1scan19 and func1scan20, the source file is found in >>> the source file list) >>> >>> <acquisitionList count="2"> >>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/> >>> <acquisition nativeID="func1scan19" sourceFileRef="rawFile1" /> >>> <acquisition nativeID="func1scan20" sourceFileRef="rawFile1" /> >>> </acquisitionList> >>> >>> It would all be covered by the following xsd: >>> >>> <xs:complexType name="AcquisitionType"> >>> <xs:annotation> >>> <xs:documentation>Scan or acquisition from original file >>> used to >>> create this peak list. A spectrumRef or an externalSpectrumID or >>> nativeID >>> plus sourceFileRef should be given .</xs:documentation> >>> </xs:annotation> >>> <xs:complexContent> >>> <xs:extension base="dx:ParamGroupType"> >>> <xs:attribute name="number" type="xs:int" >>> use="required"> >>> <xs:annotation> >>> <xs:documentation>A number for this >>> acquisition.</ >>> xs:documentation> >>> </xs:annotation> >>> </xs:attribute> >>> <xs:attribute name="spectrumRef" type="xs:IDREF" >>> use="optional"> >>> <xs:annotation> >>> <xs:documentation>This attribute must >>> reference >>> the 'id' >>> attribute of the appropriate spectrum. </xs:documentation> >>> </xs:annotation> >>> </xs:attribute> >>> <xs:attribute name="nativeID" type="xs:string" >>> use="optional"> >>> <xs:annotation> >>> <xs:documentation>This attribute references >>> the >>> native >>> spectrum identifier in a raw file. </xs:documentation> >>> </xs:annotation> >>> </xs:attribute> >>> <xs:attribute name="externalSpectrumID" >>> type="xs:string" >>> use="optional"> >>> <xs:annotation> >>> <xs:documentation>This attribute must >>> reference >>> the 'id' >>> attribute of the appropriate spectrum in an external mzML >>> file. </xs:documentation> >>> </xs:annotation> >>> </xs:attribute> >>> <xs:attribute name="sourceFileRef" type="xs:IDREF" >>> use="optional"> >>> <xs:annotation> >>> <xs:documentation>This attribute must >>> reference >>> the 'id' >>> attribute of the appropriate sourceFile. >>> </xs:documentation> >>> </xs:annotation> >>> </xs:attribute> >>> </xs:extension> >>> </xs:complexContent> >>> </xs:complexType> >>> >>> The semantic validation would be to check that at least one of the >>> attributes spectrumRef, externalSpectrumID (+sourceFileRef) or >>> nativeID >>> is given. >>> >>> Or maybe there is even more to consider? >>> >>> Fredrik >>> >>> >>> Eric Deutsch skrev: >>> >>>> Hi Fredrik and everyone, thank you for thinking about these last >>>> few >>>> problems. It seems that there are several different ways in which >>>> one >>>> might want to reference the source scans for a summed scan. Based >>>> on >>>> what's been said so far, here are my thoughts and proposal. What do >>>> you >>>> think? >>>> >>>> Currently for acquisitionList we have (in XML/XSD hybrid): >>>> --------------- >>>> <acquisitionList count="2"> >>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of >>>> spectra"/> >>>> <acquisition number="xs:int" sourceFileRef="xs:IDREF" >>>> spectrumRef="xs:IDREF"> >>>> <cvParam cvLabel="MS" (optional child of scan attribute)/> >>>> </acquisition> >>>> <acquisition number="xs:int" sourceFileRef="xs:IDREF" >>>> spectrumRef="xs:IDREF"> >>>> </acquisitionList> >>>> --------------- >>>> >>>> Frederik suggests spectrumRef -> xs:string >>>> externalSpectrumID="xs:string" >>>> >>>> This brought up the question of how would sourceFileRef reference >>>> itself >>>> if everything were in the same file? >>>> >>>> Rune points out that we want nativeID references, like for Waters: >>>> function1scan2, func1scan2, 1.2 or .... >>>> >>>> Darren suggests: >>>> externalSpectrumID="URI" >>>> externalNativeID="xs:string" >>>> >>>> ------------------------------------------- >>>> >>>> So, I suggest something like this (in XML/XSD hybrid): >>>> >>>> <acquisitionList count="2"> >>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of >>>> spectra"/> >>>> (three possible options:) >>>> <acquisition spectrumRef="xs:IDREF"> >>>> <acquisition nativeID="xs:string"> >>>> <acquisition sourceFileRef="xs:IDREF" >>>> externalSpectrumID="xs:string"> >>>> <acquisition >>>> </acquisitionList> >>>> >>>> --- >>>> >>>> Example 1: (the current spectrum is a sum of two scans which are >>>> also >>>> present in the current file as ids S57 and S58.) >>>> >>>> <acquisitionList count="2"> >>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of >>>> spectra"/> >>>> <acquisition spectrumRef="S57"> >>>> <acquisition spectrumRef="S58"> >>>> </acquisitionList> >>>> >>>> --- >>>> >>>> Example 2: (the current spectrum is a sum of two scans which had >>>> nativeIDs func1scan19 and func1scan20, the exact location of which >>>> are not specifiable) >>>> >>>> <acquisitionList count="2"> >>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of >>>> spectra"/> >>>> <acquisition nativeID="func1scan19"> >>>> <acquisition nativeID="func1scan20"> >>>> </acquisitionList> >>>> >>>> --- >>>> >>>> Example 3: (the current spectrum is a sum of two scans which are >>>> explicitly referenced externally by a specific file previously >>>> defined in the current document and with IDs in that other file) >>>> >>>> <acquisitionList count="2"> >>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of >>>> spectra"/> >>>> <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S57"> >>>> <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S58"> >>>> </acquisitionList> >>>> >>>> --- >>>> >>>> Also okay is 1+2: >>>> >>>> <acquisition spectrumRef="S57" nativeID="func1scan19"> >>>> <acquisition spectrumRef="S58" nativeID="func1scan20"> >>>> >>>> --- >>>> >>>> Also okay is 2+3: >>>> >>>> <acquisition nativeID="func1scan19" sourceFileRef="mzMLsF01" >>>> externalSpectrumID="S57"> >>>> <acquisition nativeID="func1scan20" sourceFileRef="mzMLsF01" >>>> externalSpectrumID="S58"> >>>> >>>> --- >>>> >>>> Thus, all four possible attributes are optional, and we would >>>> rely on >>>> the sematic validator to enforce: >>>> >>>> spectrumRef alone >>>> OR nativeID alone >>>> OR spectrumRef AND nativeID >>>> OR sourceFileRef AND externalSpectrumID >>>> OR sourceFileRef AND externalSpectrumID AND nativeID >>>> >>>> What do you think? A little unpleasant to have several different >>>> options, but I don't see how we could practically exclude any of >>>> the >>>> options. >>>> >>>> >>>> As a related side note, Matt also asks if we can handle the case >>>> where >>>> MS1 scans have been stripped out of a file, but the the MS2 scans >>>> still >>>> need to say something useful about their precursor scan (IDREF not >>>> possible). >>>> >>>> I have not checked this, but we should spend some time thinking >>>> about >>>> that once we have solved this problem. >>>> >>>> Thanks, >>>> Eric >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: psi...@li... >>>>> >>>>> >>>> [mailto:psidev-ms-dev- >>>> >>>> >>>>> bo...@li...] On Behalf Of Darren Kessner >>>>> Sent: Friday, May 02, 2008 9:13 AM >>>>> To: Mass spectrometry standard development >>>>> Subject: Re: [Psidev-ms-dev] Spectra from summed acquisitions in >>>>> mzML >>>>> 0.99.10 >>>>> >>>>> I think it's a bad idea to have a spectrumRef to a spectrum that >>>>> isn't >>>>> in the file. We should be consistent in the use of internal >>>>> references, all of which use IDREF so that dangling references can >>>>> be >>>>> caught during XML validation. >>>>> >>>>> External references, including those to spectra that have been >>>>> removed >>>>> for space reasons, should be indicated specifically (e.g. with >>>>> externalSpectrumID or externalNativeID) so that the reader >>>>> (human or >>>>> software) knows that they'll have to do some extra work to find >>>>> the >>>>> referent. >>>>> >>>>> >>>>> Darren >>>>> >>>>> >>>>> >>>>> On May 2, 2008, at 6:17 AM, Matt Chambers wrote: >>>>> >>>>> >>>>> >>>>>> Perhaps we should follow the same logic of the spectrum element >>>>>> itself, >>>>>> where id is required but nativeID is optional. Thus, id is >>>>>> required >>>>>> for >>>>>> a spectrum reference and a reference to the nativeID would be >>>>>> >>>>>> >>>> optional >>>> >>>> >>>>>> (but recommended!). We can't use the same attribute to point to >>>>>> >>>>>> >>>> either >>>> >>>> >>>>>> id or nativeID because then it won't be known which is being >>>>>> >>>>>> >>>> referred >>>> >>>> >>>>>> to, unless I'm missing something in Fredrik's proposal. >>>>>> >>>>>> To deal with IDs that aren't in the file, I agree with Fredrik. >>>>>> Any >>>>>> time >>>>>> we have a reference that can be to a non-existent or external >>>>>> >>>>>> >>>> element, >>>> >>>> >>>>>> we can't use IDREF. We either need to switch to xlink (in which >>>>>> case >>>>>> IDREF would probably still be ok) or fall back to string. >>>>>> However, >>>>>> since >>>>>> I think that acquisitions should be able to reference spectra in >>>>>> the >>>>>> current file, we shouldn't change it to externalSpectrumID. We >>>>>> >>>>>> >>>> should >>>> >>>> >>>>>> just document that all spectrumRef and spectrumNativeID(Ref?) >>>>>> attributes >>>>>> may refer to a spectrum in the current file or in another one, >>>>>> and >>>>>> >>>>>> >>>> in >>>> >>>> >>>>>> the former case the spectrum might not actually be there (i.e. >>>>>> MSn >>>>>> spectra referencing precursor spectra that have been stripped out >>>>>> to >>>>>> conserve space). >>>>>> >>>>>> -Matt >>>>>> >>>>>> >>>>>> Rune Schjellerup Philosof wrote: >>>>>> >>>>>> >>>>>>> I think the format by which external file elements are reference >>>>>>> should >>>>>>> be defined. >>>>>>> For instance, a reference to a Waters raw file, should that be >>>>>>> function1scan2, func1scan2, 1.2 or .... >>>>>>> >>>>>>> -- >>>>>>> Rune >>>>>>> >>>>>>> Fredrik Levander wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> There is an issue with the current mzML schema (0.99.10) when >>>>>>>> it >>>>>>>> comes >>>>>>>> to referencing the origin of acquisitions in an >>>>>>>> acquistionList of >>>>>>>> summed spectra. In most cases the referenced spectra will not >>>>>>>> be >>>>>>>> >>>>>>>> >>>> in >>>> >>>> >>>>>>>> the current mzML file, and thus the spectrumRef cannot be of >>>>>>>> the >>>>>>>> type >>>>>>>> xs:IDREF, but should be xs:string to also cover references to >>>>>>>> spectrum >>>>>>>> IDs in other mzML files, or native IDs in vendor files. >>>>>>>> >>>>>>>> The following would cover both internal and external spectrum >>>>>>>> referencing: >>>>>>>> >>>>>>>> >>>>>>>> <xs:complexType name="AcquisitionType"> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>Scan or acquisition from >>>>>>>> >>>>>>>> >>>> original raw >>>> >>>> >>>>> file used >>>>> >>>>> >>>>>>>> to create this peak list, as specified in sourceFile.</ >>>>>>>> xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> <xs:complexContent> >>>>>>>> <xs:extension base="dx:ParamGroupType"> >>>>>>>> <xs:attribute name="number" >>>>>>>> >>>>>>>> >>>> type="xs:int" >>>> >>>> >>>>> use="required"> >>>>> >>>>> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>A >>>>>>>> >>>>>>>> >>>> number for this >>>> >>>> >>>>> acquisition.</ >>>>> >>>>> >>>>>>>> xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> <xs:attribute name="spectrumRef" >>>>>>>> >>>>>>>> >>>> type="xs:string" >>>> >>>> >>>>>>>> use="required"> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>This >>>>>>>> >>>>>>>> >>>> attribute must >>>> >>>> >>>>> reference the 'id' >>>>> >>>>> >>>>>>>> attribute of the appropriate spectrum if found within an mzML >>>>>>>> file, or >>>>>>>> the native spectrum identifier in a raw file in another format. >>>>>>>> </ >>>>>>>> xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> <xs:attribute name="sourceFileRef" >>>>>>>> >>>>>>>> >>>> type="xs:IDREF" >>>> >>>> >>>>>>>> use="required"> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>This >>>>>>>> >>>>>>>> >>>> attribute must >>>> >>>> >>>>> reference the 'id' >>>>> >>>>> >>>>>>>> attribute of the appropriate sourceFile. It can also refer to >>>>>>>> the >>>>>>>> present mzML file.</xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> </xs:extension> >>>>>>>> </xs:complexContent> >>>>>>>> </xs:complexType> >>>>>>>> >>>>>>>> However, I am not sure if there are any use cases when both the >>>>>>>> summed >>>>>>>> spectrum and the original spectra are found in the same file. >>>>>>>> If >>>>>>>> not, >>>>>>>> the spectrumRef attribute should maybe be renamed to >>>>>>>> 'externalSpectrumID' or something else, since 'spectrumRef' >>>>>>>> >>>>>>>> >>>> somehow >>>> >>>> >>>>>>>> indicates that the spectrum is in the present file. >>>>>>>> >>>>>>>> If there is a need to reference spectra within the file the >>>>>>>> following >>>>>>>> may be an alternative (I think Darren proposed something >>>>>>>> similar): >>>>>>>> >>>>>>>> <xs:complexType name="AcquisitionType"> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>Scan or acquisition from >>>>>>>> >>>>>>>> >>>> original file >>>> >>>> >>>>> used to >>>>> >>>>> >>>>>>>> create this peak list. Either a spectrumRef or an >>>>>>>> >>>>>>>> >>>> externalSpectrumID >>>> >>>> >>>>>>>> plus sourceFileRef should be given .</xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> <xs:complexContent> >>>>>>>> <xs:extension base="dx:ParamGroupType"> >>>>>>>> <xs:attribute name="number" >>>>>>>> >>>>>>>> >>>> type="xs:int" >>>> >>>> >>>>> use="required"> >>>>> >>>>> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>A >>>>>>>> >>>>>>>> >>>> number for this >>>> >>>> >>>>> acquisition.</ >>>>> >>>>> >>>>>>>> xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> <xs:attribute name="spectrumRef" >>>>>>>> >>>>>>>> >>>> type="xs:IDREF" >>>> >>>> >>>>> use="optional"> >>>>> >>>>> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>This >>>>>>>> >>>>>>>> >>>> attribute must >>>> >>>> >>>>> reference the 'id' >>>>> >>>>> >>>>>>>> attribute of the appropriate spectrum. </xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> <xs:attribute name="externalSpectrumID" >>>>>>>> >>>>>>>> >>>>> type="xs:string" >>>>> >>>>> >>>>>>>> use="optional"> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>This >>>>>>>> >>>>>>>> >>>> attribute must >>>> >>>> >>>>> reference the 'id' >>>>> >>>>> >>>>>>>> attribute of the appropriate spectrum if found within an >>>>>>>> external >>>>>>>> mzML >>>>>>>> file, or the native spectrum identifier in a raw file in >>>>>>>> another >>>>>>>> format. </xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> <xs:attribute name="sourceFileRef" type="xs:IDREF" >>>>>>>> use="optional"> >>>>>>>> <xs:annotation> >>>>>>>> <xs:documentation>This >>>>>>>> >>>>>>>> >>>> attribute must >>>> >>>> >>>>> reference the 'id' >>>>> >>>>> >>>>>>>> attribute of the appropriate sourceFile. It can also refer to >>>>>>>> the >>>>>>>> present mzML file.</xs:documentation> >>>>>>>> </xs:annotation> >>>>>>>> </xs:attribute> >>>>>>>> </xs:extension> >>>>>>>> </xs:complexContent> >>>>>>>> </xs:complexType> >>>>>>>> >>>>>>>> So, main question: are there any use cases with the original >>>>>>>> scans >>>>>>>> and >>>>>>>> the summed spectrum in the same file, and is there in this >>>>>>>> case a >>>>>>>> need >>>>>>>> to distinguish clearly between external and internal >>>>>>>> referencing >>>>>>>> (second schema alternative)? >>>>>>>> >>>>>>>> A minor point is also that the documentation of the spectrum >>>>>>>> attribute >>>>>>>> nativeID should be updated to something like: >>>>>>>> >>>>>>>> The native identifier for the spectrum, used by the acquisition >>>>>>>> software. If the spectrum is reconstructed from more than one >>>>>>>> spectrum, the native identifier of the first acquisition in >>>>>>>> time >>>>>>>> should be used. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Fredrik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>>> - >>>>> >>>>> >>>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >>>>>> Don't miss this year's exciting event. There's still time to save >>>>>> $100. >>>>>> Use priority code J8TL2D2. >>>>>> >>>>>> >>>>>> >>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j >>>> av >>>> >>>> >>>>> aone >>>>> >>>>> >>>>>> _______________________________________________ >>>>>> Psidev-ms-dev mailing list >>>>>> Psi...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>>>>> >>>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> - >>>> >>>> >>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >>>>> Don't miss this year's exciting event. There's still time to save >>>>> >>>>> >>>> $100. >>>> >>>> >>>>> Use priority code J8TL2D2. >>>>> >>>>> >>>>> >>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j >>>> av >>>> >>>> >>>>> aone >>>>> _______________________________________________ >>>>> Psidev-ms-dev mailing list >>>>> Psi...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >>>> Don't miss this year's exciting event. There's still time to save >>>> $100. >>>> Use priority code J8TL2D2. >>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >>>> _______________________________________________ >>>> Psidev-ms-dev mailing list >>>> Psi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >>> Don't miss this year's exciting event. There's still time to save >>> $100. >>> Use priority code J8TL2D2. >>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >>> _______________________________________________ >>> Psidev-ms-dev mailing list >>> Psi...@li... >>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save >> $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save > $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
