Proposed XML schema for opreport -X option

[Maynard J. <may...@us...>]

Excuse the redundant posting, but I wanted to re-post with a subject 
heading that clearly identifies the topic.  My original posting was on 
Feb 13 as a reply to a posting with subject line of "Re: How to 
auto-process opreport output?".  Comments would be appreciated.

==============================================================
Attached is a proposed schema that includes about everything I can think 
of that a tool may want to extract from OProfile's sample data.

Allow me to say just a few things about how it would be used to create 
XML documents and how tools would process the XML data.

The top level element, Profile, contains exactly one each of the 
following elements: SampleInfo, SymbolDataList, and ProcessList.
 - The SampleInfo in this context describes the setup info (e.g., events 
being counted, etc.)
  -The SymbolDataList is a list of SymbolData elements containing 
general, non-process-specific information about sampled symbols.  Note 
that a SampleInfo element appears again in the SymbolData element, 
giving a tool the ability to show the number and kind of samples for a 
given symbol (regardless of the process(es) from where the samples were 
taken).  Also note the "id" attribute of SymbolData.  This id will be 
referenced by other elements (explained below).  The Bytes element is a 
bit of an odd duck.  This element has no attributes or elements 
defined.  Its intended to be a container for the binary opocode 
associated with a symbol, but since there is no "binary" data type in 
the schema language, I left it unspecified.  Finally, the LineNumberList 
and VmaOffsetTickList are, I think, pretty self-explanatory.
  - The ProcessList contains the detailed sample information for each 
process/thread for which samples occurred.  Notice that for the various 
levels of the hierarchy (process, thread, module, symbol), the 
SampleInfo element is again included so that tools can, if they wish, 
show the actual sample data at each level of the hierarchy.  Finally, 
note that in the lowest level of the hierarchy -- Symbol -- there is a 
'refid' attribute.  For each symbol, this attribute is filled in with 
the id of the corresponding global SymbolData element described above. 
This avoids having to repeat general information about a Symbol that is 
common no matter which process or thread was executing the code.

Even though I suggested in an earlier email that I would add some code 
to Junichi's patch, I decided it might be best to wait until we have 
consensus on the schema.

Regards,
-Maynard