RE: [xml-dev] Is it time for the binary XML permathread to start up aga

[Melvin Chin <mc@SoftOffice.Net>]

At 08:14 AM 2007-07-20 -0400, Costello, Roger L. wrote:

>1. Send the XML document as is, as ASCII text, without any compression
>or other alterations.

Adv: All of current XML, readable by lowest denominator of text editor.
         Not just ease for human reading, but also for debugging.
Dis: Lengthy, verbose, perhaps ok for machine-to-human, but then for
         machine-to-machine and demanding apps such as real-time or
         long docs, the inefficiency surfaces.


>2. Compress the XML document using a compression tool such as WinZip or
>Bzip, and then send the compressed document.

Basically, a compressed format is not in the same space nor purpose as
a binary format.  A long (XML text) document can still be long in binary 
format,
but readily parsed efficiently by a binary parser, while a compressed format
aims solely for compression efficiency regardless of parsing difficulty.

Adv: For compression alone, as you know, it helps in sending large files 
quickly.
Dis: But overall processing from sender (encoding side) to receiver (decoding
         side) becomes longer (for given constant CPU speed) due to extra
         overheads.

I think the variables to look at between deciding choosing compression or
not have to include CPU speeds vs bandwidth vs de/compression overheads.
For end-users, it doesn't help if gain in time on sending/receiving large 
(XML)
docs quickly gets spent on compression/decomp cycles and extra memory
movements.


>3. Encode the XML document as an ASN.1 file, and then send the ASN.1
>file.
>4. Encode the XML document a Fast Infoset file, and then send the FI
>file.
>5. Encode the XML as an Efficient XML Interchange file, and then send
>the EXI file.

These are basically "reformatting" and as long as the destination format
properly encloses your original XML instance, you can convert back and
forth without loss.  Worst case scenario, enclose as "escaped text"
in the target spec, which results in null conversion.  Basically I don't
see much point if it is solely to convert source XML into a "carrier-format"
and then back to XML again.


I see use of binary XML in demanding situations, such as huge document
processing and voluminous processing, where human assistance is not
required.  In such cases, the advantages of XML being human-readable
and other related points are of no advantage but add on to the processing
drag.  So a binary version in such applications would be most useful.

I'd look forward to a binary version (not a compressed version) so that
applications have a choice.

On interoperability, it's true that binary XML won't be readily "interoperable"
in the sense of byte-by-byte equivalence to current text-based versions.
But I believe some level of interpretation spec could be defined to allow
applications to "equate" text-versions with binary versions.  With
"dynamic" interoperability (one that includes standardised interpretation
of binary vs text entities of XML trees) instead of "static" interoperability
(byte-wise comparison, or other comparisons based on static structures
between binary vs text), I believe it could help in reducing "interoperability
loss" through introduction of binary version of XML.




>Are there other choices?  Have I phrased each choice properly?
>Under what circumstances would a choice be selected?
>What are the advantages and disadvantages of each choice?
>
>/Roger




cheers.
Melvin Chin