Welcome!

Web 2.0 Authors: Kevin Benedict, Liz McMillan, Esmeralda Swartz, Roger Strukhoff, Elizabeth White

Related Topics: Java, .NET, Linux

Java: Article

"The World's Gone Crazy with XML," Says Sun's Senior IT architect

Great sound bite. Now what about the reality?

"The world has gone crazy with XML and then Web services," writes Sun's senior IT architect Victoria Livschitz, in an article currently to be found on the official Sun Web site.

"SOAP and UDDI are getting enormous attention," she continues, "and yet, from a software engineering standpoint, they seem to me a setback rather then a step forward. We now have a generation of young programmers who think of software in terms of square brackets. An enormous mess of XML documents that are now being created by enterprises at an alarming rate will be haunting our industry for decades. With all that excitement, no one seems to have the slightest interest in basic computer science."

Great sound bite. Now what about the reality?

Standards activist Rick Jelliffe, CTO of Topologi in Australia, comments:

'I don't think [Livschitz] has twigged that XML, raised as a side-issue at the end of the article, could be helpful for the kind of problem she complains about earlier on - 'subroutines, functions, data structures, loops, and other totally abstract constructs that neglect -- no, numb -- human intuition.'   XML can allow a more human-friendly representation of things: a dog has three legs or whatever."

Microsoft's Dare Obasanjo, writing in the influential XML-DEV mailing list, writes: "Interesting."

"Too bad her comment is the equivalent of a sound bite with no substance at all," Obansajo (who works for Microsoft) continues. " I'd be curious to know why she thinks moving to XML from proprietary binary formats is a setback as opposed to a step forward. Maybe this is just Sun's way of justifying pushing replacing the XML in XML Web Services with ASN.1."

The last word though goes to XML expert Bob Wyman, who on the same list writes:

"From a 'computer science' point of view, you simply can't dispute what Livschitz has said. XML, etc. are a setback. But, she is wrong, I think, in her implicit equating of 'software engineering' with 'computer science.'

The strengths of XML, etc. are not in computer science. Rather, XML's strengths are in the human sciences of sociology, psychology, and political science. XML offers us no concepts or methods that weren't completely understood 'computer science' long before ASN.1 was first implemented in the early 80's. From a 'computer science' point of view, XML is less efficient, less expressive, etc. than ASN.1 binary encodings or the encodings of many other systems. However, because XML uses human readable tag names, because it is text based, easy to write, has an army of evangelists dedicated to it and many freely available tools for processing it, etc. XML wins in any system that values the needs of humans more than those of the machines.

XML's ability to 'win' in the human arena has enabled a great outburst of computer science as a result of the greater interchange of information and the increased ease of interchange. However, this great outpouring of utility and enablement of new computer science work has been at the cost of accepting an interchange format which is 'inferior' from the point of computer science. Of course, I think most of us accept that this cost is an acceptable one and a small price to pay in most cases.

Personally, I have always felt quite strongly that software engineering should be distinguished from computer science by recognizing that software engineering encompasses far more than the close technical scope of computer science. Where computer science is focused on algorithms and machine processes, the focus of software engineering should be on the development and deployment of software within and for systems that have human purposes as their goals. A computer scientist can, and should, focus only on the bits in the machine, a software engineer needs to consider not only the machine but also the organizational dynamics of the team that builds the software as well as the human needs of the organization that uses the software. A computer scientist couldn't help prefering ASN.1 binary encodings to XML. A software engineer, on the other hand, will often see no reasonable alternative to XML in today's world.

Virtually any argument that attempts to claim a technical superiority for XML is bound to be proved wrong by reference to ASN.1 or many other alternatives. In much the same way, most arguments that XML should 'simply be replaced' with a technically superior alternative simply expose the naiveté, ignorance, or closed-mindedness of their advocate. What is 'right' in computer science is not always what is 'right' in software engineering.

Of course, many people who read this will be wondering at this point why I, a "known" proponent of the use of ASN.1 and its encodings, am writing in defense of XML! Well, I'm not really. XML has its place and ASN.1 also has its place. XML is best used in applications where the influence of the human needs on design decisions is strongest while ASN.1 offers real value in applications where the needs of the machines dominate.

For instance, at PubSub.com, where we do content-based publish/subscribe, we speak to the outside world via HTML and XML since that is the 'language' that is most commonly understood by the world at large and the easiest format for people to generate and consume. On the other hand, all of our internal processing is done on ASN.1 binary encodings. (i.e. we convert everything to/from XML at our perimeter). The result is that we have great interoperability with the outside world by using XML and we've got great efficiency in our internal processing by using ASN.1 encodings. The best of both worlds. In the future, we will undoubtedly allow and even encourage some high volume publishers to send us data using ASN.1 encodings so that we can optimize a bit and eliminate some of the cost of translations at the perimeter -- however, I can't imagine that we would ever stop interchanging XML with the vast majority of our clients.

At the perimeter of PubSub.com's system, the human sciences and human needs dominate. In our core, it is the needs of our machines that dominate. Thus, we meld the application of software engineering and computer science.

Livschitz is right in saying that XML is a step backwards from the point of view of computer science. She is wrong in suggesting that it is anything but a tremendous step forward in software engineering."

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 (11) 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
David Webber 02/20/04 12:02:32 AM EST

Mike Plusch makes the case for ConciseXML, and there are other tools besides that offer different solution paths.

I''d urge people looking for ways to deploy user facing interfaces that make it much easier to grok XML to look at using VisualScript XML as a means to do that.

You''ll find more information on this at http://www.visualscript.com

and some interesting examples that can give you ideas around how you can use this at:

http://drrw.net/visualscripts/

Enjoy, DW.

Mike Plusch 02/19/04 09:08:47 PM EST

If you are interested in an XML-compatible syntax
that removes the ambiguity and verbosity of XML 1.0,
ConciseXML is an open, language-independent markup
syntax that removes 9 constraints in the XML syntax
that makes it possible to handle every type of data including non-hierarchial data, program logic, binary,
and traditional document markup.

http://www.ConciseXML.org

The specification is completely free and open, and parser implementations are also encouraged to be open source.

I am the co-creator of ConciseXML and would love to
find a standards body to adopt ConciseXML. I''d like
to be able to use XML everywhere, but things need to
change to make that possible.

_Mike Plusch
Clear Methods, Inc.
CTO

Thomas Cox 02/19/04 10:54:37 AM EST

I''ve spent the last two years working with XML on a full-time basis, writing an applicataion to extract data from any arbitrary XML file. I''ve seen thousands of unique customer and third-party XML documents in that time.

From that perspective, I have to agree with Livschitz. Over 90% of the documents and associated DTDs or XSDs (if any) I see are a disaster. Of course, that''s not the directly the fault of XML, but XML does have some serious flaws (some pointed out by previous posters to this forum) that contribute to the mess. Not that XML doesn''t have many useful applications - RSS is one - but it is ill suited for many others, particularly when the data volume and/or data complexity is high.

I was particularly annoyed by Wyman''s specious contrast between "computer science" and "software engineering". Bad data structures - the problem underlying almost all bad XML - aren''t any more readable to humans than computers.

Further, if you care about scalability, performance, security, or data integrity then you should definitely pay more attention to computer science than Wyman''s fuzzy ideas about what SE should be. (FWIW, there''s already a discipline referred to as "Human Factors" or "Usability". It''s critical to good applications, but it doesn''t - and *shouldn''t* - usually deal with low-level constructs like data-interchange formats.)

Again, XML has its uses, but it is abused far more often than not.

googler 02/19/04 06:11:35 AM EST

She's probably trying to introduce ASN.1 into the non-tech world, in the same breath as XML (which people have head of and are interested in) so that people think Sun invented it. Sun One , ASN One.

It sounds like the kind of whining you got when VHS triumphed over Betamax. Live with it, move on or become irrelevant.

Olderthan Sixteen 02/19/04 05:35:25 AM EST

It is quite evident that XML is useful for many practical task. However, many people are finding that it is enough to say "XML solves this" to be viewed as visionaries. The result is that there is no meaningful discussion on the shortcomings and all we get is hype, hype, hype. The result is a very widespread misuse of XML.

In the article, there is a claim that XML is better than ASN.1. But in the field, architects have to deal with people claiming that XML is better than RDBMS, that it is easier to program with XQUERY than with container managed EJBs, that there is no more a need for RAD tools and other such nonsense. All of this is achieved magically by something called "XML". This is the real problem which is taking computer engineering, not just computer science, a step backwards.

It is not really a failing of XML as such, it is just lack of knowledge, which finds food in XML hype. Poeple not involved in technology just cannot tell the difference, as everything from Web Services, SOAP, XML databases, XPath, XSLT, etc. ... gets called XML. And then when someone complains that this is leading to nowhere, they come up with a comparison of XML and ASN.1 !!! Please, let's have some sanity.

David Webber 02/18/04 11:46:09 PM EST

Mike Plusch's example of boolean is exactly on the mark.

Head over to the OASIS CAM TC site and see how using CAM on top of schema goes after solving all this morass for you!

http://www.oasis-open.org/committees/cam

will get you a bunch of information on using CAM.

DW.

Mike Plusch 02/18/04 11:04:14 PM EST

XML is a step backwards as far as data representation goes.
The whole attribute vs. element issues is the tip of
the iceberg. XML was not designed for data.

Yes, I know that this is against conventional wisdom
of "XML is great". To show the truth in this statement, ask yourself or anyone who knows XML as simple question: How would you represent a boolean true value in XML syntax?
If XML was designed for data, this would be a trivial question. A boolean value is a simple data type. Any programmer could immediately tell you how to represent true in a programming language. If you are able to figure out the answer, then ask three other developers and see if they give you the same answer. If no two developers give you the same answer, you have just demonstrated to yourself just one of the serious ambiguity issues of XML.

David Webber 02/18/04 10:03:44 PM EST

I am focusing in on the morass of unmaintainable XML that is being created. This is a sad fact, and because noone is listening and learning the lessons of EDI before. To ameloriate this headlong rush to chaos, the OASIS CAM TC has created a system and the jCAM implementation to allow rigorous and consistent XML transactions and scripts to be assembled.

People should heed the message that Livschitz is delivering, and look to build better XML as a result by using techniques such as OASIS CAM is teaching.

DW, Chair OASIS CAM TC

Cameron Roe 02/18/04 11:55:24 AM EST

The ''real truth'' is that communicating to machines is hard. XML is, to my mind, an attempt to produce the ''Esparanto'' of machine to machine communication. It''s a fine notion but it loses something in the translation (pun intended).
I think that the software engineering world suffers from the very human notion of when it''s holding a hammer, the world looks like a nail. To us an analogy, you can''t use a hammer(XML) to drive a Twinky(distributed computing) through a piece of wood(internet). :)
The hammer(XML) is a very usefull tool in the correct context, but it is not the solution to all problems, and will probably, in the end, be a solution to a small subset of the engineering problems currently faced by the software industry.

Wilfred Springer 02/18/04 10:43:11 AM EST

> those of us who actually do this in the real world know the truth of the usefulness of XML and Web Services.

Hmmmmm, I wonder if a lot of people *really* know the truth about the usefulness of XML and Web Services. If that were true, then you would not expect seeing so many people embracing it as a general-purpose tool. This is (part of ) the truth:

There is no mutual agreement on how to do transactions across vendors. (ACID, or AC(I)D)
There is no mutual agreement on what is needed to have reliability across vendors.
There is no mutual agreement on policy management across vendors.

Just a couple of things that don't exist in the Web Services space. Sure, we have loads of specifications, but these specifications are sometimes only interesting from a theoritical perspective. Web Services will become truly interesting once all vendors agree on an integrated Web Services stack providing mechanisms to support reliability and transaction management.

Fortunately, we have JSR 208. Somewhere in the future, I will be able to deploy my services without really caring too much about the protocols. I will be able to leave that to the responsibility of the service providers; that will allow me to bind my service to ASN.1, ebMS, WS-I, REST, or what else is out there.

Heywood Jablome 02/18/04 09:50:33 AM EST

Such is the difference between theory and practice. Theorists, such as Livschitz, can pontificate all they want to puff up their pet beliefs but those of us who actually do this in the real world know the truth of the usefulness of XML and Web Services.