Hi David, Nice! I was dubious about whether I might get a byte count from a SAX parser, but in fact eXpat does have a XML_GetCurrentByteIndex() method. Guess I have been making things overly complicated for no good reason. Sometimes it takes a fresh perspective to find the simplest solution.
Thanks for your help! --Brendan On Jan 5, 4:25 pm, David Shteynberg <[email protected]> wrote: > Hi Brendan, > > I considered this option but it is not so easy to do with iProphet > drawing the results for one search run from multiple possible search > engines a single MS runs spectra may now be reported across several > msms_run_summary elements. Computing how many will be reported is > possible, and requires traversal of the input pepXML files to add the > number of msms_run_summary elements across them all. However, the > number of spectra in different msms_run_summary elements may be quite > different so using this value for a progress bar report may not be > best. > > For your progress bar can you instead consider the file-size and bytes read? > > Thank you, > -David > > On Sun, Dec 25, 2011 at 10:52 AM, Brendan MacLean > > > > > > > > <[email protected]> wrote: > > The BiblioSpec library builder builds spectral libraries from many > > peptide search formats. It has long supported pepXML from > > PeptideProphet. I am now looking at expanding this support to include > > pepXML from iProphet. One issue I have encountered, however, is that > > unlike the PeptideProphet pepXML it does not seem possible to know how > > many <msms_run_summary> elements the file contains without reading the > > entire file. In the PeptideProphet element: > > > <analysis_summary analysis="peptideprophet" ...> > > > The number of <inputfile> elements usually corresponds to the number > > of <msms_run_summary> to follow, which is extremely useful in > > presenting progress information during pepXML parsing. > > > Unfortunately, in the corresponding iProphet element: > > > <analysis_summary analysis="interprophet" ...> > > > The <inputfile> elements are for pepXML files, which themselves may > > have contained results for many <msms_run_summary> elements, and many > > <inputfile> elements. > > > It sure would be nice to have some way of knowing early in the file > > parsing how many <msms_run_summary> elements there might be. Also, it > > seems like the current strategy of discarding all <inputfile> elements > > from included pepXML files and representing them as only a single > > <inputfile> element for the containing pepXML file loses useful > > information. Perhaps <inputfile> elements could be nested to preserve > > the original input files. > > > Any other way to have the pepXML forecast the number of > > <msms_run_summary> elements would suit my current need as well. > > > Thanks for considering. > > > --Brendan > > > -- > > You received this message because you are subscribed to the Google Groups > > "spctools-discuss" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/spctools-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en.
