[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Is it time for the binary XML permathread to start up aga
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|