W3C home > Mailing lists > Public > public-xml-binary@w3.org > February 2005

[XML-Binary] ZIP file format using XPATH for directory entries proposal

From: Fred P. <fprog26@hotmail.com>
Date: Fri, 18 Feb 2005 02:39:51 -0500
Message-ID: <BAY104-F11FD7894AF20FB6A024F18A76E0@phx.gbl>
To: public-xml-binary@w3.org

Hi everyone,

Here's some very straight-forward proposal:

The following proposal is made to address, the following use cases:

- 3.2 Floating Point Arrays in the Energy Industry
- 3.3 X3D Graphics Model Compression, Serialization and Transmission
- 3.5 Web Services within the Enterprise
- 3.6 Embedding External Data in XML Documents
- 3.7 Electronic Documents

and to some point to this use case and others where complexity matters:
- 3.4 Web Services for Small Devices

Many here might know the OASIS OpenDocument format,
which consist of a ZIP files of XML documents.

The following idea is an extension of this idea.

It was derived by looking at FixML 4.3, svg and seisdata
and various other use cases, which needs binary content.

Proposed name/extension:
.BML  = Binary Markup Language
.ZML  = Zipped Markup Language
.7ML  = 7-zip Markup Language
.XMLZ = eXtensible Markup Language Zipped (similar to svgz)

One of the use cases needed a 'very small footprint' for a decompressor.

I looked around for commonly used compression format, they are mainly:
bzip2, gzip, tar, jar/zip, arj, rar, ace, 7-zip

bzip2 and gzip were already considered there main problem are:
- They cannot random access a file  (solid archive)
- They cannot contain multiple file (mostly via tar)
- They are complex to implement for small device.

tar cannot be compressed, so it's eliminated.

rar and ace are proprietary with only extracting algorithms being provided, 
so it's eliminated.

arj was interesting, but not quite enough:
+ Random access
+ Can contain multiple file
+ Source code available on sourceforge (GPL)
+ Did about the same as zip for mixed and binary content
- Did worst than zip on compression of english text, log file or sorted word 
- Is claimed to be: "ARJ is a CPU-intensive program"

zip/jar was interesting, but with some algo/size limitations:
+ Random access
+ Can contain multiple file
+ Algorithm is available
+ Source code available
+ Industry standard
+ Compress/Decompress about the same speed/size than gzip in fast mode
- 2 GB limitation
- Does not support Unicode file names
- 1.5x to 3x bigger than 7-zip

7-zip was interesting, with some speed limitation:
+ Random access
+ Can contain multiple file
+ Algorithm is available
+ Source code available (LGPL)
+ Small code size for decompressing: about 5 KB
+ Very suitable for embedded applications
+ Small memory requirements for decompressing (depend from dictionary size)
+ Supports encryption with AES-256 algorithm
+ Use LZMA derived from LZ77
+ Support Unicode file names
+ Compression of archive headers
+ Support more than 2 GB content (2^64 bytes)
- Not an industry standard
- Decompressing speed: about 10-20 MB/s on 2 GHz CPU
- Compressing   speed: about     1 MB/s on 2 GHz CPU
-  4 times slower than gzip when compressing/decompressing in fast mode 
- 10 times slower than gzip when compressing in maximum mode
- Total time including transfer is 1.5x slower than gzip or zip


As a result, zip and 7-zip can be considered.

The obvious advantage of zip is that it is an industry standard
and works fast/size and similar to gzip.

The obvious advantage of 7-zip is file size over slow links (28Kbps or 
Unicode file names and the small 5KB footprint for the decompressor.


The goal is to use an XPath like syntax for directories within the archive.

With 7-zip, this means Unicode Entities can be supported,
while this is not possible with zip.

Question to debate are:
- Do we put file extensions or not?
  + Easier for external viewer.
  - XPATH Association must be done on the filename WITHOUT the extension.

- Do we want to support 2 GB+ archives (zip64, 7-zip) ?
- Do we want to support Unicode XPath (7-zip) ?
- Is file size more important than compression speed ?

- Should we support many compression scheme: gzip, bzip2, zip and 7-zip ?

Assuming the following test case:

    <linename>westcam 2811</linename>
  <trace>0.0 0.0 468.34 3.245672E04 6.9762345E05 ... (3001 floats)</trace>
  <trace> ... </trace>

Would be stored like this:

Where /seisdata.xml contains:
    <linename>westcam 2811</linename>

Where /seisdata/trace[1].bin contains opaque
IEEE floating point binary digits.

The <trace> node could be empty like this <trace></trace>

The advantage of the placeholder is for conventional DOM manipulation
to assess that such thing as zipped binary data exist...
and should be fetched on the fly, as needed.

In this case, if you just want the XML without the binary,
it should load quickly and be easy to parse/modify/save.

+ This means accessing individual trace is extremelly fast and easy,
  since the archive does not have to be fully extracted or parsed.

+ Also, no encoding is needed.

+ It's very easy to create/modify/extract/view any files within the archive.

+++ Readability is preserved.
+++ No big changes to existing XML tools/parser

Another way, would be the following:


This means that new nodes are appended using zip operations instead.

It also means that the XML parser must work a bit harder.
It is also safer since the original is kept as is
for financial, banking, crucial data, where a modification log is needed.


could contain <![XDATA[/seisdata/header[6].xml]]> or not.

Obviously, adding such placeholder for XML add-on would be penalising.

However, an alternative scenario or syntax could be derived:


i.e. pkunzip -d seisdata.zip /seisdata/trace[*].bin

XDATA: XML data     [parsable by DOM]
BDATA: Binary data  [non parsable]

Another use case, Word2000 HTML:

Currently, it save into a "folder"
with external metadata, images, sounds.
That could be zipped like this:




XML Binary Characterization Use cases:

OASIS OpenDocument:

Compression Algorithm Comparision:

7-zip file format:

Arj file format:

Rar file format:

Zip file format:

XPath tutorial:

CDATA tutorial:


Comments, suggestions, improvements, feed back welcome ? =)

Sincerely yours,

Received on Friday, 18 February 2005 07:40:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:40:09 UTC