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
