The suggestion JSB has made looks to be in accordance with a "pure" XML
or HTML layout, but in the DSTO application I'm involved in we're using
the Xerces-C parser to build our DOM at low level, so the approach of
tagging each table point will result in many more short nodes in the DOM
rather than one node with a very long content string.  In effect,
navigating the DOM tree could be slowed down quite a lot (including for
access to data not related to the table), and the DOM might require more
memory just for the parser's internal structure.  

Since we load the table string into a 1-D numeric array as part of the
run-time initialisation, and would similarly pre-load the individual
points if we had to, this proposed structure would not affect our
real-time computational performance, but it might make the actual
initialisation quite slow.

On the whole the current structure seems a reasonable compromise.

As far as the ungridded data goes, I'm working on it at present, and in
the structure I've developed so far, again the use of more detail in
more nodes will not affect run-time speed but may slow down both
initialisation and navigation of the DOM, as well as using more memory.

Dan Newman

Reply via email to