Comments on: Putting XML in the fast lane

Data exchange format is just too slow, some say. But there's debate over the best way to make Extensible Markup Language fly.

[catmando]

Why Not Compress

If the transmission of XML is the concern, why not compress the data during the transmission process? That way it can be stored in it's native format for editing and searching, but compressed to a small state for the transmission.

Some storage systems like Oracle allow for behind the scenes compression so compression could even spill over to storage systems and be transparent to the consumers and producers of XML.

[Johnny Mnemonic]

Binary implies compression...

In order to maintain compatibility among various
systems, everyone must agree as to how the bits
are to me transformed. When we discuss binary formats
it implies compression. But, what form of
compression? The entire packet, header, body, etc. At
what point do you compress? At what level of the
stack? Eveyone must agree so everyone can understand
the transmission.

That doesn't really solve speed issues

You have to factor in the time to compress and decompress the data.

[stumiller]

compression doesn't speed parsing

Compression will only save transmission times, but it will not speed the parsing of the data, which I imagine is at least 50% of the bottleneck. Binary XML would help here.

[Jean-Paul Figer]

HTML was verbose too...

...and was the winner. Http protocol also exchanges text information. Tim Bray is right : the benefits of text information are so huge than binary XML is a bad idea. Optimizations can always be done locally if needed. Same story as assembler compared to high level languages.

Coherent Informatics (CI)

The company Exos Services Inc., in Denver has already devloped a very efficent XML platform. It prioritizes internet stream packets, which cause no bogg down. Check them out http://www.exosservices.com/.

http://www.som.tulane.edu/tccep/documents/CI_Defined.pdf

Its amazing

CI

Nick, how do you know about CI?

Bray is just wrong

First, looking at binary format such as Corba, it's much more interoperable than xml these day. Just go to the Axis forum and see how many people having problem with .net and java?

Get real. Corba has both communication interoperabability and source code interoperability. Soap is a true backward standard with these regards.

I work on both and I know the heart of it. I developed enterprise applications using both and I know. Corba is 5 to 10 times faster. It's much more scalable.

So, what's the problem of Corba? These are addressed by webservice/soap, and that's why it shines, not because of text based transportation:

1) It's not embraced by all vendor.
2) It does not use web as the mean of transportation.
3) The addressing scheme is really stupid (not using a simple http url, but a weird and long IOR string
4) Looking using JNDI/nameservice. Most of the time, people know exactly what the address is and not needed to use the repository server for the service.
5) Screw up programming model in Corba. Put it in one short: it's stupid. a) It's like black whole, sucking all your programming into it. There's an article talking about this. b) It forces you to use Corba objects when you don't need to, or want to. c) The architecture is too complex, and vendors hardly get it right. Example would be taken well known, matured libraries such as Ace/Tao and test it in a reall world app, it would not handle Tcp/Ip package corruption. Or Mico for example, it would not have time out option (with the version I last checked a while ago). This shows it's how hard you have to work to get these right.

So, Soap/WS advantage is not text base (text helps a little). Corba's problem has nothing to do with binary. Interoperability is not because of text or not (it's opened standard).

Another misleading point is not only the network that slows down the connection. For example: take out the network, and use the same computer for the client and the server. It's still very slow. Why? CPU cycles. XML consumes so much CPU cycles that 100% is utilize. This is not the case for Corba.

My advice is to look at the problem seriously. Work with it like I do. Find the exact problem and fix it. Do not speculate blindly. Bray is just too blind, and bias, because it's his baby.

Here's some similarity between Soap/ws and Corba to show that some of the myth Soap/ws brings:

1) Both use another declaration language: wsdl for soap and idl for corba. Idl is much easier to master.

2) Programing style most vendors support is to generate the stub, skeleton from the declaration language. So no different here. Both are cumbersome, and taken the same amount of work.

[Johnny Mnemonic]

Except...

CORBA was the dream, but, Microsoft killed it.
Corba was way ahead of its time. But, it offers
far more than just data and services
interoperability. XML offers a simple data transport
whereas CORBA offers full data/object/method
distribution. Far more complex and difficult to
integrate, and, currently, far too much overhead.
What you gain in data transport you lose in
processing speed.

Excellent comparision of WS vs. CORBA

I couldn't agree more. When I brief people on Web Services, I tell them it's next generation CORBA.

My company uses the IFX XML standard in financial applications. The documents can be quite large and intricate. They are typically used between dedicated clients and servers, where a substantial investment is made in their development. Performance is ALWAYS an issue. As you pointed out, and as the Sun article showed, the XMLlanguage object binding can be the dominant cost. This is network independent - as you pointed out, for the intraprocess example.

Sun article: http://java.sun.com/developer/technicalArticles/WebServices/fastWS/
and
http://java.sun.com/developer/technicalArticles/xml/fastinfoset/

[My-Self]

Transparent compression when/if needed

There is no reason to create a new standard / fragment XML compatibility. Transparent compression when/if needed is the way to go.

HTML is verbose too, and the proper way to handle it is to setup on the fly compression (such as Apache's mod_deflate).
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html

It significantly cuts bandwidth usage, speeds up transmission with very little impact on the processing power. The best part is once setup, you just forget about it, it's completely transparent.

[Al Johnsons]

forget about it

http://www.analogstereo.com/seat_leon_owners_manual.htm

[stumiller]

performance is never an issue (for long)

If initial research puts the performance boost at 3x for binary XML, then at the rate which hardware performance grows this will be matched in 2 years. XML's usage will surely grow, but XML itself will not get more complex. In a few years from now, even the most constrained devices (PDA, cameras, personal devices) will likely have ample computing power and storage to handle today's text-based XML. Why bother with what will undoubtedly become a fragmented market of open and proprietary binary-XML specs?

XML tokenization?

Why not simply add a header tag section to the top of an XML document that defines what 'short tags' (tokens) in the rest of the document should expand to? It's the old data dictionary song, with a faster beat... very easy to automate prior to transmission.
<root>
<dictionary>
<define token="a1" fullname="LastName"/>
</dictionary>
<a1>Smith</a1>
</root>

People are already using binary formats for XML interchange

Whether Tim Bray likes it or not, people are already using binary interchange formats.

The question before the W3C is whether we should try to gain support for a single such format, to promote interoperability, or whether people should go off and use the 80 or so formats in widespread use today.

Liam
(W3C XML Activity Lead)

Fast streaming XML documents

Many concerns about integration and compatibility are being resolved by companies implementing the XML and service oriented architectures. At the same time due to lack of proper standards and improper implementations, it is still hard to have large amounts of information bundled within the XML documents for transactions. There is a need to create compression standards and a robust XML architectures. However, a certain vendor controlling and pushing a format may ultimately prove to be a downfall for the rapid growth in XML adoption due to competing formats.