Help on Distinct patterns :
This is the amount of distinct patterns in the Xml stream. Most of the time, there is a single pattern that is repeated many times in the stream. But, much more rarely, and depending on design there may be more than one.
We are dealing with structure patterns, ie combinations of elements and attributes, regardless to the actual content enclosed by the structure. An indicator for the content can be found elsewhere in this report. Close this one
Help on Pattern occurences :
This is the amount of times the main pattern occurs in the Xml stream. The higher, the more "tabular" the stream is.
By main pattern we mean the most seen of the patterns that have been detected. Most of the time, the main pattern is exactly the single pattern detected in the stream. Close this one
Help on Pattern height :
This is the amount of lines top to bottom for the main pattern. This figure does not include every carriage returns, especially those from the content itself, thus there may be a slight difference between the number in the report and what you'll see by counting it yourself.
By main pattern we mean the most seen of the patterns that have been detected. Most of the time, the main pattern is exactly the single pattern detected in the stream. Thanks to that, as an observation the pattern height times the pattern occurences approaches greatly the total stream amount of lines (elsewhere in the report). Close this one
Help on Pattern size :
This is the size in bytes of the main pattern, regardless of the content it encloses. By main pattern we mean the most seen of the patterns that have been detected. Most of the time, the main pattern is exactly the single pattern detected in the stream. Why is this figure important ? that's because that's a basis to compare with a tremendous potential gain obtained by flattening the pattern structure, thus leading to a new flatten pattern size. Close this one
Help on Flatten Pattern size :
This is the size in bytes of the main pattern, once flatten, regardless of the content it encloses. By main pattern we mean the most seen of the patterns that have been detected. Most of the time, the main pattern is exactly the single pattern detected in the stream. This figure compares with the original pattern size in order to show a tremendous gain on size, for the pattern instance itself, and of course for the overall stream. Below are explanations on the process of flattening patterns.

Flattening patterns is the process of replacing candidate elements with attributes, in order to avoid the overhead effect of end-tags in the size of the stream. What are candidate elements ? that's elements with 1-cardinality, that is sharing an elementary and single relation with another element or attribute. The Xml document below models a person name, and is subsequently flatten :

Original Xml sample :
 <person>
  <firstname>John</firstname>
  <lastname>Lepers</lastname>
 </person>
Modified Xml :
 <person firstname="John" lastname="Lepers"/>
which leads to a 39% gain on size just for this. When the process is performed on the whole stream, this produces a predictable gain which is figured out as the flatten pattern gain, see next indicator. Close this one
Help on Flatten Pattern Gain :
This is the gain in percent as a result of flattening all patterns in the stream. A flatten pattern always reduces (in worst case it equals) the size of an original pattern because by design it removes end-tags. For more details, see Flatten Pattern size above.
The tremendous gain obtained by such a process calls for critics. Indeed, the Xml structure is different, so it is likely to break rigid client applications that expected to see the original structure. As a rule, it must be said that this process is not actually performed on the input stream. It is simply suggested. It is suggested that, if those who design or generate Xml streams pay attention to this particular point, then they may have benefits in several areas of performance including size and parsing speed.
Also as a sidenote for all transforms suggested in this report, one can question rigid Xml-based client applications that would stop from working any longer if the incoming Xml streams are slightly changed in their structure. First of all, the structure is either described by a DTD (Document Type Definition) or by any combination of namespaces, and as long as the client application simply parses keywords and doesn't assume things on element hierarchies, then client applications will continue working fine. On the contrary, those client applications which have hardcoded hierarchies within C++ code will fail, but that is more a matter of questionable code design on the client side, than Xml overuse.
Otherwise this gain can be cumulated to other gains described elsewhere in this report. Close this one