Read more on Cloud Computing
March 23, 2005 4:00 AM PST
Faster XML ahead?
- Related Stories
-
Putting XML in the fast lane
January 13, 2005
But critics say the group's favored approach could cause major compatibility problems, among other things.
XML is fast becoming a widely used way of formatting and saving business documents such as purchase orders. But for certain applications--sending data to set-top boxes, for instance, and offering interactive programs on cell phones--representing data using XML is simply too bulky, say proponents for more efficient XML.
What's new:
The Net's top standards body is getting closer to speeding up XML-based software, a move that could benefit everyone from cell phone carriers to television broadcasters to the military.
Bottom line:
The possibility of the World Wide Web Consortium pursuing more efficient XML through a binary, rather than text, format is causing concerns over interoperability and questions about the future direction of XML.
If XML were zippier, say some, cell phone companies, for example, could meet consumer demand for more complex programs. The Air Force, too, has expressed interest in using speedier XML formats for embedded computing applications, such as those found in fighter jets (click here for related PDF).
A W3C committee recently recommended that the group address the problem by moving away from the traditional way of saving XML data--in text format--and instead create a standard for a binary format. W3C working group recommendations are generally taken up as formal standards efforts, which means the group is one step closer to a major change in the XML standard.
The recommendation still has to be approved by the W3C's Advisory Committee and the W3C's director. But a vote to move forward with a binary XML standard could happen late this summer, said Liam Quin, the XML activity lead at the W3C.
Binarians and contrarians
The issue, though, is already causing controversy among the XML cognoscenti, who worry that significant changes to the specification could cause compatibility headaches and face significant hurdles in getting adopted.
Attendees of a February meeting in Boston argued for different technical approaches to speeding up XML. Some questioned the need to take up a binary XML effort at all, according to people present at the meeting.
We shouldn't "mess around with (XML) just for a short-term fix (when) in the long term, the industry is going to fix that problem naturally," said Eric Newcomer, chief technology officer at Iona Technologies and an attendee of the meeting. Newcomer says current XML performance "is not all that bad" and that the controversy is "reminiscent of the argument about a decade ago, when everyone said the World Wide Web is too slow and it will never take off."
Right now, all the information in an XML document, such as a name and address, is represented as text. Binary formats compress the XML
12 comments
Join the conversation! Add your comment (Log in or register)
Cheers,
Kevin
For example, instead of:
<books>
<book type='hardback'>
<title>Atlas Shrugged</title>
<author>Ayn Rand</author>
<isbn id='1' rating='good'>0525934189</isbn>
</book>
</books>
Use:
books{
book(type='hardback'){
title{Atlas Shrugged}
author{Ayn Rand}
isbn(id=1,rating=good){0525934189}
}
}
Attribution is obvious as it is in (), the loss of the duplicating closing tag removes the number of bytes of the opening tag.
This format works without any line feeds and can be translated into XML if needed.
Already supported, and chances are most of the transfers occur over HTTP anyway.
That said, I often recommend a custom binary encoding between the J2ME app and a proxy for the app running in a servlet container. Doing Java on either end makes it easy to move data between the two, see my tip at <a class="jive-link-external" href="http://developers.sun.com/techtopics/mobility/midp/ttips/clientserv/" target="_newWindow">http://developers.sun.com/techtopics/mobility/midp/ttips/clientserv/</a> for the details.
Eric
<a class="jive-link-external" href="http://www.ericgiguere.com/" target="_newWindow">http://www.ericgiguere.com/</a>
I believe that if a binary XML format is standardized, there should be some standard means for the sending and receiving programs to negotiate what they support, so that the binary protocol will only be used when both sides support it. If different binary encodings need to be specified, there should be some way of identifying them, and if two programs don't support any common binary encodings, the text form should always be available as a fallback.
In some 'closed' applications, where the "client" is known to support only one format, a binary only XML engine can be used to save code space and processor cycles. On 'open' systems, most applications would probably have to support text XML parsing as well as zero or more binary encodings.
An advantage to having this standardized is that the XML documents will be in a form that can be decoded by any XML parser that conforms to the standard and supports the specific binary encoding scheme. There may be a few of these different encodings, but they should all be flexible enough that no software vendor feels obligated to create their own proprietary encoding because they think the standardized ones are inadequate.
I was just thinking about XML and the speed-performance idea. And the impact unreadable binary files could have.
To my opinion sending complete XML-files is just like upgrading software by sending the complete package over and over again.
If it is about sending large files that contain for an great part the same information send previously. Why not just send PATCHES (or a nicer word: INCREMENTALS) to that file?
It needs communication protocols. It needs software adaption. But it brings fabulous sending-speed performance.
It might even increase SECURITY by not sending all information every time.
Please add your comment to this idea.
T. Nijmeijer
Delft, Netherlands
Though the bandwidth considerations are not inconsiderable, a larger part of the problem is the work required to parse, validate, and deserialize the data from its text form to the binary formats. Some embedded devices (where this is most likely to be best applied) like set-top boxes and mobile phones are limited in the CPU and memory available to handle this process and a standardized binary XML encoding/representation would reduce the headroom required on these devices to handle more sophisticated applications.
I have already seen CDATA and other unrestricted elements being used by some XML applications to pass what is effectively BASE64 encoded binary records around, and this is not decodable by anything other than another application that already knows how to interpret the binary structure. A standardized binary XML encoding would solve this as it would still identify the elements.
Uhhh, well let's see then I guess then the VARIANT in VB is fast?
How about a unversal datatype in SQL Server or ORACLE then?
Should we wait 10 years?
If we fix the problem now, it will be superfast later...
However, who in their right mind should even think that the W3C have anything to do with making an XML standard is dreaming!!!
W3C did not make HTML a standard as it's not even a business and is mostly clueless intellectual types who have no idea what business is.
A standard becomes a standard when everyone starts using it, NOT when W3C says, "This is the standard and you must conform."
It's amazing the crap I hear on this IT ezines....They get Mr. Preppy with the long winded resume that says, "I worked for so-and-so but was and am NOT currently in the trenches actually doing the coding or actually using the software or service..."