XML no magic bullet

By Dave Kearns
Network World Directories Newsletter, 07/24/02

If there's one thing attendees should have taken away from last week's Catalyst conference, it's the notion that XML is not the magic bullet for identity management, Web services or any other technology initiative.

Burton Group CEO Jamie Lewis tried to emphasize this point is his closing remarks, and I hope everyone was listening when he said, " Products that support XML won't interoperate 'automagically.' "

XML is, at its base, a listing of ordered pairs. One of each pair is a descriptor or identifier, while the second element is a value. The identifiers are defined in the syntax, and there's an infinitely extensible list of them available to the person coding the application.

In practice, I could choose to call the element used to identify you to the directory the " login_name " and base an application for authentication and authorization on that element. Someone else could choose to define a similar element, used for the same purpose, and call it " user_name. " The two applications could not interoperate without some discussions and agreements on where the overlap between user_name and login_name occurred and how the differences would be handled.

Worse, the two programmers could each have chosen to use an element called " location " - but one meant it to hold a value of building, floor and office number, while the other used it to define the user as local or remote. No amount of negotiation could reconcile this, short of renaming one of the elements.

<aside> Before you start writing me to complain that I'm grossly simplifying the problem - I'm aware of that! This is an exaggerated example to show, clearly, the potential problems. </aside>

Long ago (almost 10 years ago - a veritable technology lifetime) I was involved with instituting Electronic Data Interchange (EDI) in my company. The EDI standards (called " x11 " and " EDIFACT " for the major U.S. and European standards bodies) also defined ordered pairs within highly structured documents.

EDI was not an extensible language the way XML is. Each ordered pair, each new document had to be approved by the governing standards body, and this was only done after long deliberation to remove any ambiguity from the definition. The deliberation was also needed to determine which elements were required to be used in the document and which were optional.

Even so, before two enterprises (called " trading partners " ) could begin to exchange EDI documents, such as a purchase order, a document called a Trading Partner Agreement (TPA) had to be drawn up. In it, each side specified the documents and versions they would use, as well as which of the optional elements. But even further, each party would specify in excruciating detail exactly what sort of values would show up in each ordered pair - even though the standard supposedly defined them. Negotiating the TPA could easily take many months because the lawyers had to get involved to determine what would happen in each instance that the rules laid out in the TPA weren't followed.

XML was supposed to free us from all of that negotiation. Instead, though, it requires a whole new layer of negotiation as documents are constructed in an ad hoc manner between trading partners.

To overcome some of these problems, groups have formed to develop non-extensible subsets of XML for various activities (I've written frequently about Directory Services Markup Language and Security Assertion Markup Language). This hasn't worked as well as promised, but that's a story for another day. For now, note that XML is very important, something you should be involved with, but its going to take a lot of work on everybody's part to make it deliver on its promise.