Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


XML Authors: Jayaram Krishnaswamy, Chris Pollach, Jason Bloomberg, Peter Silva, Mehdi Daoudi

Related Topics: XML Magazine

XML: Article

Does XML 1.0 "Suck"?

Does XML 1.0 "Suck"?

(July 21, 2003) - When the CEO of a well-known company trying to get Web services to take off claims that XML sucks, what are Web services developers supposed to make of the claim?

XML 1.0 isn't the lingua franca it's cracked up to be, Mike Plusch from Clear Methods is claiming, it's "unreliable, ambiguous, verbose, and isn't designed to work with logic and complex data structures," he says.

Plusch is offering his own cure, the perfect drink as it were for those thirsty for a techno-fix: and he is branding it, simply, Water.

Developer Colin Saxton, of the UK-based integration software company Exel Computer Systems plc, agrees that XML is bloated. "I would go as far as saying that XML should not have been developed as a text specific document," he says.

"Why did they not agree on a specification to represent data in binary format instead of text?" Saxton asks. "Developers from all over the world could then have written general purpose editors to decode the data and represent it in text form but store the data in a nice and compact format."

Saxton is cruelly ironic, as he summons up a tongue-in-cheek scenario, purporting to be the way the W3C must have worked back in 1998.

"I know, we will create a new data representation format for Web services and we will base this new format on SGML? Doh...!!! This idea obviously must have started from someone who has shares in networking since Web services based on XML will increase bandwidth enough for them to have to re-cable the world?"

IBM's Max B Klau says that he has "long suspected that XML will go the way of SQL -balkanization, probably worse."

"It's not surprising," Klau explains, "that one has to read and understand the ever verbose and obscure and evolving XML specs to do anything useful. XML was once a child with great promise to solve certain problems. But like any teen idol pushed into stardom, it attempted to solve too many things, some it was not well-suited for."

"The joke among developers," says Klau, "is to XML-ize every thing they can get their hands on. For example, I was wondering why some products use XML for a small .ini file that can be more easily read and configure in value-pairs format, rather than forcing user to strain their eyes to read XML <> brackets. For high-speed data exchange, why not standardize some "self-described" binary-based format? Since XML substrate is now typically consume by machine, not humans, the ASCII-based XML is doomed to be slow."

One developer who thinks everybody's getting it wrong is M. Saleem Khan Suri, who says that, in his view, "Most of us are using XML in the wrong way."

"It's not for display but for parsing," he says, adding: "The important stuff here is that the Microsoft .NET is totally based on XML and its against the practice of Microsoft to follow such a standard. So the important question is: is Microsoft going to sell its .NET platform with XML? Or will they launch something named MSXML (Microsoft XML) for the sake of monopoly?"

More Stories By Jeremy Geelan

Jeremy Geelan is Chairman & CEO of the 21st Century Internet Group, Inc. and an Executive Academy Member of the International Academy of Digital Arts & Sciences. Formerly he was President & COO at Cloud Expo, Inc. and Conference Chair of the worldwide Cloud Expo series. He appears regularly at conferences and trade shows, speaking to technology audiences across six continents. You can follow him on twitter: @jg21.

Comments (14) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Nalini Wanichai 08/25/03 04:32:05 PM EDT

'XML 1.0 isn't the lingua franca it's cracked up to be, Mike Plusch from Clear Methods is claiming, it's "unreliable, ambiguous, verbose, and isn't designed to work with logic and complex data structures," he says.'

Obviously, Mr. Plusch does not understand the purpose behind XML.
1. You can design XML application to be concise such as using ... versus ... like some of the e-commerce spec.
2. It does not intend to be a legal document so it does not have to be precise. The meaning of XML tag name is not supposed to mean anything, does not have to be semantically corrected.
3. XML is intended to use as a format for structured data so it is great for complex data structure. And since it is a declarative language it is not intend to use in procedural programming.

Most of the reasons people find XML difficult to use because they have not understood the fundamental principle about this technology.

Martin Ladner 07/22/03 06:08:00 PM EDT

- The apparent simplicity of XML is an illusion quickly dispelled when serious consideration is given to the requirements for data transfer between businesses in different functional areas. Because XML is not an efficient way to represent data, has no agreed-up message infrastructure, lacks standard business data formats and definitions agreed upon across functional areas, and distracts companies from better alternatives, it hinders rather than helps BPR and commerce.
- XML lacks standard business formats with standard definitions; therefore, it doesn't help companies identify common data to be broadly shared across functional areas and therefore actually hinders Business Process Reengineering. XML doesn't claim to be a standard; it's a blank tablet for which vendors can't agree how to communicate the definitions they are trying to develop in narrow functional areas. The result thus far is multiple proprietary solutions that encourage stovepiping through their lack of broad acceptance across functional areas.
- XML lacks a message-based infrastructure with built-in loss/corruption detection and routing. Again, proprietary programs and extensions are the current method of dealing with these omissions.
- XML is so wasteful of bandwidth that engineers are talking about special firmware to identify and compress XML 'documents'. By contrast, it still takes XML six times as much bandwidth as it does ANSI X12 to transfer similar data even before the XML requirement to send a DTD is factored in.
- ANSI X12 is an example of an efficient and standard message standard that has standard meanings agreed upon across functional areas to support commerce and BPR. The decades-long process of developing these meanings has helped to define the data exchange requirements between enterprises. X12's infrastructure automatically handles acknowledgment and guards agains the effects of message corruption. XML has none of these advantages.
- The same basic issues of data definition and communications infrastructure must be wrestled with for any interface. XML users have to start from scratch for every interface negotiation. X12 users already have a common dictionary from which to select the subset of data they need to represent and common formats with which to succinctly represent the data. Simple Web-based code to convert X12 to a human-readable format is only three pages. Furthermore, one can purchase an X12 translator for the price of a high-end PC; so, cost is no longer the excuse for throwing out decades of experience and starting over.
- Even in the limited situation where one wishes to represent data structures in-house, XML wastes bandwidth and parsing resources. It's logically unnecessary to name closing tags (because all non-singleton tags must be nested); however, XML requires them to be named anyway. The typical interface needs to pass multiple records that have the same structure; XML expects field names to be redundantly passed for each 'record'. Surely a first-year programmer could come up with a better format than that and toss in a checksum and parser to match.
- The bottom line is that XML is usually the wrong tool. It isn't suitable for use in commerce, in BPR, or even in the limited situation where a company owns both ends of the communication channel. It is seldom the best answer to real-world business problems.
=Marty=

Brian Forsythe 07/22/03 10:22:00 AM EDT

This article sounds like a hoax someone mocked up. I'll just assume it's for real...

The testimonies in this article are testimonies to to a shallow understanding of what xml represents and its strengths. Was xml initially immature? Sure, what isn't? It's not a programming language, it's not a be-all and end-all of data representation. These guys sound like procedural guys knocking OO programming because they just don't get it. Reminds me of a quote I once heard (excuse me for this not being verbatim): "A story is told about a CIO whose application in development is to be object-oriented because it's developed in C++. What's funny is that some people don't realize that's a joke."

Also, these guys seems to miss half the point -- XML is human-readable and editable. If we encode everything in binary, this forces consumers of the data to use proprietary tools. To quote the guy in the article, "Doh!"

Jay Conne 07/22/03 10:07:00 AM EDT

The "XML Sucks" headline that the author chose is clearly provocative, but it also consistant with what many acknowledge. Let's look at the real issue.

COMPLEXITY:
The world could have continued to function with the geocentric view of the heavens but the simplification of the heliocentric view made many formerly unsolvable problems manageable. It reduced the number of units you need to deal with to solve a problem - the real epistemological issue. We can only hold 7 plus or minus 2 units in our heads at once.

I like Christopher Fry's remark: "Technical people don't recognize a complexity problem." They just get macho about proving that they can solve any problem with any technology. They just work harder. The alternative is to identify opportunities for simplification and work smarter.

Humans deserve better than max complexity.

SEPARATION OF DATA, CODE & PRESENTATION:
This standard principle of good design is essential for maintainable code. However, the choices of where to draw the lines should be dictated by the application designer or architect. It sould not be dictated by limitations in the tools. It's very powerful to casually be able to make a data value active. That means it is represented by a method call which could even be a Web service. Water language and ConciseXML make those choices easy.

It is also sometimes vlauable to make presentation decisions dynamic, eg. calculate font size or base color on a global context like is the account overdue. Thus the introduction of JavaScript and its ilk.

Since XML was designed as a verbose data repsentation syntax it requires clumsy tranformations into forms the common programming languages can consume. The industry has multiple solutions to that problem. Look closely at www.ConciseXML.org for the reasoning behind inventing an improved XML. I'd like to see it become the future XML standard for all the reasons discussed on that site.

ConcoseXML was an necessary, enabling invention for the Water language to achieve it's vision of tremendous simplification of Web Services development, deployment and maintenance.

See www.WaterLanguage.org for a free trial of the IDE and runtime. YOu'll also find the Water book TOC with many linked chapters in PDF.

Also - look at the article on the security model based on principles from secure operating systems.

Personally speaking, I have known the founders for over a decade. Their years of analyzing the basic problems and inventing solutions to them make them rare people. How often do you find people that can cut through the confusion of conventional wisdom of a complex area of human knowledge and then offer an elegant alternative? And then how rare is it for them to bring that innovation to the marketplace?

So let's stop the cheap shots and discover what's here.

Steve Demuth 07/22/03 08:20:00 AM EDT

Amen! The amount of code we write to marshal to and from XML into native objects is insane, the bandwidth requirements are insane, and the bizzare uses to which people XML (such as, e.g., writing the XSLT transform LANGUAGE as an XML dialect) are over the top.

But, it's the only universal data exchange format we've got, so we're going to be living with it for a long time to come.

fido dido 07/21/03 07:56:00 PM EDT

Yeah, it is a bad choice for simple ini files, but remember ini files that used to have to 'fake' hierarchical settings ?
No one said i had to send xml across the wire. its just easierthan strapping on another 'binarizing/de~' layer on to the communication stack to save a lot of bytes. But i dont think moving to xml is causing the bandwidth requirements to shoot up. Peanuts compared to all that music (and the ever bloating JDK) downloads.

R. Reed 07/21/03 05:30:00 PM EDT

These are self-serving comments by a CEO of a company that has something to gain by exploiting the "complexity" of XML. The truth is that XML is a data representation format, not a programming language. Those that confuse the two are doomed for failure. XML serves as a standards-based format on top of which more complex (and "balkanized") formats can be created.

XML sucks? Too late. It's here to stay.

R. Reed

Ed Tijaplak 07/22/03 11:16:00 AM EDT

> "Why did they not agree on a specification to represent data in binary format instead of text?" Saxton asks"
.. This is a joke, right ? This cannot be a serious remark. Some of the arguments against XML offered in the article above are just plain silly. I think this is just another 'flamer' title to provoke an outburst of posts defending XML. And yeah, looks like it worked as usual.

Jay Conne 07/22/03 10:08:00 AM EDT

The "XML Sucks" headline that the author chose is clearly provocative, but it also consistant with what many acknowledge. Let's look at the real issue.

COMPLEXITY:
The world could have continued to function with the geocentric view of the heavens but the simplification of the heliocentric view made many formerly unsolvable problems manageable. It reduced the number of units you need to deal with to solve a problem - the real epistemological issue. We can only hold 7 plus or minus 2 units in our heads at once.

I like Christopher Fry's remark: "Technical people don't recognize a complexity problem." They just get macho about proving that they can solve any problem with any technology. They just work harder. The alternative is to identify opportunities for simplification and work smarter.

Humans deserve better than max complexity.

SEPARATION OF DATA, CODE & PRESENTATION:
This standard principle of good design is essential for maintainable code. However, the choices of where to draw the lines should be dictated by the application designer or architect. It sould not be dictated by limitations in the tools. It's very powerful to casually be able to make a data value active. That means it is represented by a method call which could even be a Web service. Water language and ConciseXML make those choices easy.

It is also sometimes vlauable to make presentation decisions dynamic, eg. calculate font size or base color on a global context like is the account overdue. Thus the introduction of JavaScript and its ilk.

Since XML was designed as a verbose data repsentation syntax it requires clumsy tranformations into forms the common programming languages can consume. The industry has multiple solutions to that problem. Look closely at www.ConciseXML.org for the reasoning behind inventing an improved XML. I'd like to see it become the future XML standard for all the reasons discussed on that site.

ConcoseXML was an necessary, enabling invention for the Water language to achieve it's vision of tremendous simplification of Web Services development, deployment and maintenance.

See www.WaterLanguage.org for a free trial of the IDE and runtime. YOu'll also find the Water book TOC with many linked chapters in PDF.

Also - look at the article on the security model based on principles from secure operating systems.

Personally speaking, I have known the founders for over a decade. Their years of analyzing the basic problems and inventing solutions to them make them rare people. How often do you find people that can cut through the confusion of conventional wisdom of a complex area of human knowledge and then offer an elegant alternative? And then how rare is it for them to bring that innovation to the marketplace?

So let's stop the cheap shots and discover what's here.

Graeme Riddell 07/22/03 10:05:00 AM EDT

The saying goes that when "all you have is a hammer, everything looks like a nail". XML is great for what it was designed for, ie, platform independent data representation, including complex structures, thus allowing distributed implementations to be more loosely coupled and flexible. Add XMLSchema to that and it's especially powerful. But as with most things, a sprinkling of common sense is also required - it should not be used for every representation of data.

Luis Araujo 07/26/03 05:57:00 PM EDT

XML is meant to be extended and specialized, as it is being now through WSDL, and all others related to Web Services.

07/21/03 08:47:00 PM EDT

Desperate last try of a company that is about to disapear!

D. Knox 07/21/03 07:36:00 PM EDT

We already have binary represesntations of data for middleware over a network that is independent of platform. It's called CORBA and J2EE (RMI-IIOP). Before that, we would get self-describing data structures from legacy mainframes using (you guessed it) structured data and structured messages.

XML has its strengths. No solution solves all problems. Sounds like the gripe is just another C-level hallucination.

Tony Leotta 07/21/03 05:06:00 PM EDT

We are using BBuilder 2.5 to create interactive forms based on XSD Schema that allow us to develop web based applications that drive Web Services in record time.

XML does not suck??...no...but it needs a lot of tools before it is useful.

Basically the mapping of SQL Databases to XML is hard and we have spent years develoiping tools that make it easier.

As far as encoded Binary...XML is not the correct tool for sending binary...try FTP its faster. :)