Rube Goldberg, Pulitzer Prize-winning cartoonist who illustrated complex ways to achieve easy results, saw his cartoons as "symbols of man's capacity for exerting maximum effort to accomplish minimal results." He believed there were two ways to do things: simple and hard, and that a surprising number of people preferred the latter.

At this writing the XML-Dev mailing list is debating the role of XML for IETF protocols (more specifically, the requirement to use XML Schema when defining XML-based IETF protocols). (XML-Dev is a high-traffic mailing list targeting XML developers. Readers are encouraged to join and participate at www.xml.org/xml/xmldev.shtml).

Why the concern? XML Schema has been a W3C Technical Recommendation for well over a year. You'd expect the members of XML-Dev (many of whom are well-known thought leaders in the XML community) to endorse the use of XML-based IETF protocols. While the group seems to endorse the concept of XML-based protocols, controversy arises when these protocols must use XML Schema to define the elements, attributes, structures, and datatypes used by the protocol. Depending on whom you talk to, XML Schema may be regarded as overly complicated or a panacea for supporting both simple and complex datatypes.

The source of the controversy is a new (6/4/2002) Internet Draft, "Guidelines for the Use of XML within IETF Protocols" (downloadable from http://search.ietf.org/internet-drafts/draft-hollenbeck- ietf-xml-guidelines-05.txt), that describes basic XML concepts, analyzes alternatives in the use of XML, and provides guidelines for using XML within IETF standards-track protocols.

While XML wasn't originally designed to be a protocol, its ability to model complex structures in an open manner lends itself to such. A quick glance at recent Internet Drafts reveals over 40 separate initiatives using XML. It became fairly obvious that some sort of "best practices" for designing XML-based protocols would be needed. Section 4.6 the Internet Draft recommends that XML Schema be adopted as the standard formal mechanism to define structural and data content constraints for XML protocols. Specifically:

Protocols should use an appropriate formalism for defining validity of XML protocol elements. XML Schema should be used as the formalism in the absence of clearly stated reasons to choose another.

This seemingly harmless statement has caused a bit of an uproar. Miloslav Nic, founder of Zvon (www.zvon.org), states flatly: "It would be a disaster if IETF adopted XML Schema." An XML Schema expert, having designed and built the free XML Schema tutorials on the Zvon site, he readily admits that each time he approaches XML Schema he feels "like a novice." Jiri Jirat, coauthor of the tutorials, also admits having "difficulty." Both men are quite familiar with XML and XML-related technologies, having developed over 15 in-depth tutorials for Zvon.org. If these guys are having trouble understanding the spec, what hope does an average developer or group of analysts have? As they say, "We're not aware of anyone who would claim that he or she really understands the specification."

The XML Schema specification is overly ambiguous, enabling developers to interpret its various aspects in radically different ways. According to Miloslav, "Our interpretation can change several times during a single discussion." Specifications are supposed to cut through the clutter by clearly defining the terms, concepts, syntax, and rules for working with a particular technology. XML Schema seems to have failed us in this area.

Realizing the intricate nature of the spec, the designers produced an XML Schema Primer. While useful, it fails to clearly illustrate the more arcane portions of the overall specification. Understanding the primer is clearly not enough. "If you get away from it for a week or two, it's like starting from the beginning," says Miloslav. "Adopting XML Schema for future standards development could create tremendous problems for everyone."

Not everyone feels this way. According to JP Morgenthal (coeditor-in-chief of XML-Journal), "While it's true that XML is designed to be simple, there's no reason that concepts, tools, and applications built using XML need to be implicitly simple." In JP's opinion, "exchanging data across stove-piped applications and different organizations requires a complex representation that best allows organizations to ensure equality and cleanliness of the data."

While JP raises some interesting points, nothing prevents a comparatively simple solution from solving a rather complex task. Indeed, a primary reason for the popularity of Web services is that they're relatively easy to understand and implement. RELAX NG proves that difficult validation requirements can be met using fairly simple (i.e., elegant) designs. RELAX NG is capable of performing much of the functionality of XML Schema (and more) using a compact, easy-to-understand specification. The more mature XML Schema, however, has been endorsed by the W3C (which some rather short-sighted managers feel should be a requirement). The XML community must avoid painting itself (or being painted) into a corner with XML Schema. Other, possibly better, alternatives are available - each should be explored in its own right.

What do you think? Debate the merits of XML Schema, RELAX NG, Schematron, et al. in the XML-Journal Forums at www.sys-con.com/fusetalk/categories.cfm?catid=4.