efficient XML

["Duane Nickull" <duane@xmlglobal.com>]

After reviewing several archives and the recent posts to my messages, I can
summarize the subject of creating efficient XML in to the following.  This
is a very vague overview but I beleive it accurately reflects the direction
we should go in.

1.  It appears that no one has really done any in-depth performance
measurements to ascertain what constitutes efficient XML by testing over
multiple parsers.  The language the parser is written in seems to be the
single largest factor in processing time.  The order seems to be C/C++
(fastest)/Perl, Python, (fast) and then Java (slowest).

2.  The post parsing processes (ie handlers) will likely consume most of the
processing overhead.

3.  The best way to receive incoming messages seems to be a simple parse
with a single handler to decide what the "payload" is and where to route it.
This allows an efficient routing to the appropriate application without
incurring unnecessary processing overhead.

4.  The use of attributes should ideally be kept to a minimum (This reflects
emerging style "conventions" as well as "intuition" as to efficient XML.)

5.  The length of element names does not appear to have any real big effect
on parsing/processing with relatively small sized documents (under 250 kb).
There does not seem to be any great requirement for abbrieviating elements
if they can be kept to 20  characters or less.

6.  Using Mixed camel case seems to be the
<CanadianSpelling>favoured</CanadianSpelling> convention for most XML.

7.  We should avoid unnecessary levels of recursion.  Keeping the XML fairly
flat is expected to have a nominal impact of parsing/processing.  My
personal belief is that this will play a larger part with XML input trees
that have many branches.

Let's all keep our eyes open for more data on this subject as it becomes
available.

Duane Nickull
XML GLobal