Is there anyone working on a binary version of XML?

[Samuel R. Blackburn]

XML in its current form cannot handle "binary" data at all.
At best, you would have to convert non-text data to text.
This is usually done via base64.

You could create your own version of XML that could easily
handle non-text data. All you need do is add one attribute to
any XML element that provides the length (in bytes) of the
non-text data. For example:

<GIF bin:length="4096">GIF89a[4090 non-text bytes]</GIF>

The "bin:length" attribute could tell your parser to stop parsing
and store the 4096 bytes following the closing > of the element.
After the 4096 bytes have been stored, start parsing again.

The down side of this approach is:

1) bin:length would have to be agreed on by all binary parsers out there
2) binary XML files cannot be parsed by non-binary aware parsers
(in other words, every parser in the world today)

HTH,

Sam

-----Original Message-----
From: Stephen D. Williams <sdw at lig.net>
To: xml-dev at ic.ac.uk <xml-dev at ic.ac.uk>
Date: Thursday, March 25, 1999 2:04 PM
Subject: Is there anyone working on a binary version of XML?


>I know, I know, this is anathema to what many of you feel is the essence of
>XML, and I agree to a point.
>I have come to feel however that there is room for a "works-as-if" binary
>analogue to text based XML.  Something that is totally subservient to the
>standard and has exactly equivalent features, but that is highly efficient
>for processing at all levels and easily converted to and from text based
>XML.
>
>In using XML in real-world application work and designing future
>infrastructure that is highly scalable and efficient while making use of
>XML, I have come to the conclusion that I need a standard way to deal with
>an XML analogue that is binary.  There are a multitude of performance
>problems that this solves, not only in parsing and exporting, but
processing
>of related data inside applications.
>
>Before I make all the details and ideas public, I would like to know if
>there is any serious precedent directly dealing with XML.
>
>My design has highly efficient Java processing in mind, but is not specific
>to any particular language.
>Compression is a secondary, but associated issue.
>
>Thanks
>sdw
>--
>OptimaLogic - Finding Optimal Solutions
>Web/Crypto/OO/Unix/Comm/Video/DBMS
>sdw at lig.net   Stephen D. Williams  Senior Consultant/Architect
>http://sdw.st
>43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax
>5Jan1999
>
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)


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