Representing Large Tabular Data Blocks

Mike Mclinn mmclinn at
Fri Nov 19 16:48:30 GMT 1999


I am converting a number of existing proprietary file formats
to a general XML format.  The nature of the data I am working
with is very large, very well formatted blocks of data.
To give a point of reference, these files are used for data
transfer within the CAD industry.  

The natural XML solution would be of course to embed each
data value within an element or element attribute.  Such as:
<Point XYZ="324.1241 121.1214 -12.4521" NORMAL="0.0 0.0 1.0"/>
However, when you replicate this point element a hundred 
thousand times or so, you get an enormous increase in file
size.  Thus raising the question of XML efficiency.  

One possible solution is to compress the resulting files.
However, this is a very undesirable option in my case for
a variety of reasons.  Primarily compatibility and dependency

Another possible solution is to use a single element to bound
all points, using some sort of delimiters to separate records,
such as:
324.1241 121.1241 -12.4521, 0.0 0.0 1.0, 0.707 0.707 0.0|
This works to some extent, though it seems a pretty drastic
break from standard XML data schemes.  Unfortunately, to
handle this nicely a customized parser is needed.  
Essentially, this method is providing a template or
macro encoded in an element attribute that defines the
contents of the element.  

Thus, if anyone could provide opinions / comments on the 
following issues, I'd be greatly appreciative:

Is there a good way of representing bulk data embedded in
an XML file, without relying on external compression for

Is the concept of using structured element contents 
a viable method in this case?

Thanks a lot!

Michael McLinn

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list