Standards and Vocabularies

Standards and Vocabularies

At the XML ’99 conference, Steve McVey of Sterling Commerce remarked, “XML is very flexible. Everyone can do their own thing, and, by golly, everyone is!” The increas-ing prevalence and use of XML as a key, important business tool has resulted in its use in every nook and cranny where data is consumed and produced. In the case of business and industry, its use has spurred the development of document structures and markup ele-ments specific to industries, industry segments, and individual businesses. These speci-fied document structures and markup elements are known as vocabularies. Just as in the English sense of the word, a vocabulary is a set of agreed-upon language constructs that mean the same things to all parties using them. In many ways, vocabularies that are defined within user communities and have a well-defined mechanisms for their mainte-nance are called standards. But this usage of the term standard is somewhat controver-sial. Many consider a standard to be one that has been in use by a large population for a given number of years, whereas others consider a standard to be a well-defined specifica-tion that addresses the needs of a wide user base. Despite the definition, the net result of the widespread use of XML has resulted in hundreds of industry vocabularies, specifica-tions, and standards.

So, what exactly is an XML standard? This question is answered in two parts. The first concerns the nature of a standard itself. Some will take issue with the term standard when what may really be meant is initiative, application, or recommendation. Each of these terms has definite validity and good reasons why it should be used instead of the marshmallow-soft, inaccurate term standard. However, the lesser of all evils demands that some expression be chosen. Inaccurate as it is, various forces have compelled the use of the term standard when agreement is really what is meant. For the purposes of this chapter, a standard is considered to be an agreement among multiple parties about the definition, representation, or use of data and/or the technology used to exchange data. If the chosen term still offends you, the reader, we encourage a mental “search and replace” for standard with whatever term you find most appropriate.

Basically, standards are really about one thing: getting agreement. A standard represents a codified representation of an agreement on how to perform a process or implement a technology. For horizontal technologies, a standard represents an agreement on the repre-sentation or implementation of a technology. For example, in the United States, electrical outlets are 120 volts AC at 60 Hz using a particular outlet shape, whereas in the United Kingdom, electrical outlets are 220 volts AC at 50 Hz using a different outlet shape. On the other hand, vertical or business standards represent an agreement on a particular business process or methodology. For example, the United States legal system uses a spe-cific language and process for the conduct of its operations and processes, whereas other legal systems use different languages and processes.

The second part of the answer to the preceding question is that the basis of all the stan-dards mentioned in this document is that they define an XML tag set, document type def-inition (DTD), or a fragment thereof. Standards that do not comprise a definition of XML tags, DTDs, or their interchange are not covered in this chapter.

The types of entities that are creating standards are almost as wide and varying as the number of standards themselves, but they generally fall into one of the following categories:

   Governmental bodies

   International or nongovernmental formal standards bodies

   Vertical industry consortia

   Ad-hoc groups of companies

   Individual companies

   Academic institutions

   Individuals

Many equate standards with the individuals or organizations that create them. The reason for this is that the quality of a standard is dependent on the process that created it. Standards organizations differ on many areas that will determine how completely a specification is developed, and to what extent it will be used. These areas include the following:

   The level of enforcement

   The definition process

   The management process

   The number and nature of participants

Clearly, the level of enforcement of a standard depends on whether a governmental body or a group of companies has developed the specification in question. Many standards that are government created and regulated are enforced for practical, safety, or regulatory rea-sons and as a result have the force of law to back them up. However, governmental and many international standards have a more rigorous, rigid process by which they are defined and agreed to, whereas industry consortia and smaller company efforts are a more fluid and rapid process. In addition, as the standards efforts get smaller in scope, the nature of their management and the size of their participation becomes more “closed” and proprietary in scope.

What Is an Open Standard?

Many standards, whether created by industry, government, or individual companies, are touted as being “open” standards that can be adopted by the industry or market as a whole. Of course, this implies that open is a positive term, but what does it really mean? Some describe a technology or specification as “open” if they mean that it isn’t propri-etary. In that sense, the word is being used as an opposite to the word proprietary, which many consider to be pejorative. To many, proprietary means closed to outside develop-ment and viewing, closed minded, not customer centric, and slow to change. This is sim-ply not the case with most proprietary standards, and so we must consider a different definition for open.

However, we are describing here not only specifications and standards that are “out in the open” and can be viewed in their entirety by all interested parties but also an “open process.” An open process means that the forces and efforts that are employed in the cre-ation of the specification itself are open. Meetings are publicized, held outside the con-fines of a single dominant company, and voting processes for modifications to the specification are well understood. Most importantly, any party that is interested in con-tributing and can bring resources to bear on a certain problem should be allowed to con-tribute in a truly “open” process. Although W3C and other organizations follow this open-process model, not all other XML specifications and “standards” do.

Another good definition of openness comes not in the definition of the specification but in the manner with which it is used. XML’s “openness” means that it can be created by Corporation A’s tools and processed by Corporation B, C, or D’s tools or open-source applications and tools—or it can be created and processed in any combination of differ-ent tools and applications by different or competing tools vendors. For vendors of soft-ware applications who use “open” XML protocols and standards, this means that their software can be replaced. This is primarily an advantage to the consumer, who has increased choice in who and how they choose to have their problems addressed. However, this is also an advantage for the software vendor in that it can develop open interfaces that keep its software applications always current and open for modification. In addition, no company can do everything well. The adoption of open standards allows companies to “play well” with each other in the space and reinforce their own products’ best features.

The Standards-Creation Process

The work that is done by standards committees falls into one of two camps: the least common denominator (LCD) or the greatest common denominator (GCD). As a result of the constant tug-of-war present in standards working groups, final specifications are a compromise of one of two sorts. In LCD specifications, the specification reflects all the elements that could be agreed upon by all parties. If this means that a specification with 60 elements was whittled down to only 10, then the result is the lowest common denomi-nator with which all parties can agree. Another variation on this is that the specification contains all the suggestions of all the parties. This means that everyone at least has some of his or her suggestions embodied in the final result. This “greatest common denomina-tor” approach results in a fat, bloated specification that is too large for everyone and not specific for anyone. LCD approaches result in specifications that are customized with add-ons that are often proprietary and company specific. GCD approaches result in spec-ifications that are partially implemented on a selective basis with companies at odds over which parts of the specification they will choose to implement. Either solution is a poor choice for the implementing company.

One of the features of XML is that it is extremely easy to create a new document format. As a result, the proliferation of XML formats and standards is tremendous. Likewise, the potential for duplication of labor and competing standards is very high. These conflicting standards then require users to map between data formats as they cross industries or competing standards adoption. In the end, competing standards makes it a headache for everyone in the industry to adopt XML, and this is a potential barrier to long-term XML adoption.

With all this in mind, is technology even a consideration in developing standards, or is it just an excuse to get companies and industries together to agree on issues they may never have agreed on in the past? It is quite likely that XML is merely just a crutch for indus-tries to lean on while they agree on a universal representation for a particular business process or technology representation.