Standards Organizations: Who Is Creating the Standards?

Standards Organizations: Who Is Creating the Standards?

As mentioned earlier, it is almost as important to identify who is creating a given specification as detailing the specification itself. The organization that is producing the standard provides key signals about the quality, prospects of adoption, and longevity of the given specification. In fact, different organizations proposing the very same specification could meet drastically different challenges as they attempt to bring the specification to “market.”

That’s right, the word market can be applied in the context of discussing specifications and standards. After all, a specification is just words on a piece of paper or text in an electronic document. The specification needs to be adopted, used, and pulled in different directions by users of different needs before it can be considered to be a “standard.” Therefore, a wide range of specifications-writing bodies have different amounts of influ-ence and pull in the market. This section discusses the various institutions that are creat-ing XML-based specifications and how they are influencing how XML specifications are being created today.

The World Wide Web Consortium (W3C)

In the XML world, the World Wide Web Consortium (W3C) is the preeminent standards-setting body. Hosted by the Laboratory for Computer Science at MIT, by INRIA and Keio University with support from DARPA, and by the European Commission, the W3C cut its teeth originally on the Hypertext Markup Language (HTML) and has maintained its position as the foremost standards-setting body for markup language ever since.

Founded by Tim Berners-Lee (the same individual who founded the Web itself) in October 1994, the W3C is focused on developing standards for the interoperability and technical evolution of the Web. To underscore this goal, the W3C has produced an impressive number of specifications, totaling over 35 in just five years that are in wide-spread use throughout the globe. The W3C has amassed support from a wide array of corporations, academic institutions, governmental and nongovernmental bodies, and pri-vate individuals. To say that its word is the gold currency of the industry is an understate-ment. In the words of the organization, W3C’s technology specifications help make the Web a “robust, scalable, and adaptive infrastructure for a world of information.”

To meet these needs, the W3C has a core set of goals that drive its specification develop-ment and direction. First and foremost is its commitment to universal access of Web functionality for all different cultures, educations, abilities, material resources, delivery platforms, and physical limitations. This goal is very much in sync with the design goals for HTML as well as XML. A second goal of the organization is to develop an environment called the “Semantic Web” that allows users to maximize their use of Web resources. Finally, the third part of its “three-legged stool” of goals is to develop a “Web of Trust” that helps to guide the development of the Web in consideration of the legal, commercial, and social issues raised by this technology.

The W3C promotes its mission to the millions of people using its specifications by solic-iting feedback from its member organizations as well as the Web community at large. The W3C then utilizes this feedback to create Web technologies and specifications that can be published to the community as recommendations, which is the W3C non-politi-cally charged word for standard. The technological framework is based on three central principles: interoperability, evolution, and decentralization. The interoperability principle requires that the various specifications must be able to work with each other and any two systems that comply to the specification should be able to communicate with each other. The evolution principle requires that specifications be able to change as the environment for the technology likewise changes. This latter principle addresses the fact that Internet technologies change at lightning speed, requiring specifications that can likewise stay up-to-date and relevant. The final principle centers on the fact that the Web is a decentraliz-ing force, not having a central control authority or bottleneck. W3C standards must be able to scale to global proportions while simultaneously preventing bottlenecks, errors, or dependencies on central control mechanisms.

The W3C accomplishes its task through the use of working groups, interest groups, and coordination groups, which serve as the main specification generating documentation and communication activities of the organization. These groups are divided into five domains that facilitate these activities: the Architecture domain, which focuses on underlying “core” Web architectures, the Document Formats domain, which works on presentation-level specifications, the Interaction domain, which aims to improve user interaction and document creation on the Web, the Technology and Society domain, which seeks to syn-chronize technological developments with social, legal, and public policy concerns, and the Web Accessibility Initiative (WAI), which aims to improve the usability of the Web by individuals with disabilities. In addition, the Technical Architecture Group (TAG) was created in July of 2001 to provide a means for guiding, documenting, and synchronizing architectural issues as they appear in cross-technology environments. TAG will be impor-tant as the use of W3C technologies continues to proliferate.

Guided by these design principles, mission statements, and goals, the W3C organization has published dozens of recommendations and proposals at various states of development and approval. Table 19.1 shows some of these key specifications.

TABLE 19.1    W3C Recommendations as of October 2001

The Internet Engineering Task Force (IETF)

Before the W3C even existed, the Internet Engineering Task Force (IETF) was the main source of technical specifications and policies for the Internet. First convening in 1986, the IETF has been creating the fundamental protocols and technologies that have been powering the Internet since it has been an ongoing concern.

Despite the wealth of specifications created by the IETF, it isn’t a formal standards body per se. The IETF is a large, open, international community of network designers, opera-tors, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet, but it doesn’t have a formalized membership or organizational structure. It is formed as a loosely self-organized group of people who contribute their resources to solving various problems in the Internet space, but it doesn’t operate as a corporation with directors, members, and dues. This simplistic structure has allowed the IETF to focus on one thing: the development and promotion of technical specifications for the Internet.

The group’s core of the operations focuses on identifying and proposing solutions to important technical problems faced by the Internet community, specifying protocols to solve these problems, making recommendations for the adoption and standardization of those protocols, facilitating technology transfer for those protocols, and providing a forum for the exchange of information between the various participants in the adoption process.

Because the organization is a loose collection of voluntary contributors, the format for specifications generation is through IETF meetings and periodic gatherings. Anyone may register and attend these meetings because there are no formal membership processes. The IETF is nominally managed by the Internet Society (ISOC), but in a very much hands-off manner. The process of IETF standardization is managed by the Internet Engineering Steering Group (IESG). The IESG manages the output of the IETF working groups as well as helps to form and dissolve IETF working groups.

The IETF focuses on eight key areas of protocol development: application-level proto-cols, Internet protocols for routing packets and the Domain Name Service (DNS), opera-tional and network-management protocols, routing protocols, security protocols, transport services, user services, and other general protocols.

IETF standards are published as ”Request for Comments” (RFCs), although many of them carry much the same weight as general standards. There are, in fact, six kinds of RFCs: proposed standards, draft standards, Internet standards (or “full standards”), experimental protocols, informational documents, and historical standards. Every RFC first starts out as an Internet Draft (I-D). I-Ds can be written by any working group mem-ber; therefore, you can always tell a person who doesn’t understand the IETF due to his bragging about publishing an Internet Draft (when it in fact takes no significant effort). Internet Drafts are tentative documents that are meant for readers to comment on, and they automatically expire after six months. Once an I-D is published, it is reviewed by other members of the various working groups and then is escorted through the standards process by various IETF and IESG members. Finally, once the draft has been approved by all parties, it becomes an RFC. Only the first three of the RFC classes (proposed, draft, and full) are considered to be actual standards within the IETF. Examples of IETF RFCs are shown in Table 19.2.

TABLE 19.2    Some IETF RFCs

The registry system for the various IETF activities is managed by the Internet Assigned Numbers Authority (IANA). The IANA keeps track of the various protocol items as they are updated and managed. This includes such items as TCP port numbers and MIME types. Historically, IANA has also been the manager of the root of the Domain Name System (DNS), but this responsibility was passed to the Internet Corporation for Assigned Names and Numbers (ICANN) as the domain name market exploded with demand and swamped IANA’s capability and authority.

Much of the IETF RFCs form the basis for XML and HTML standards, including the HTTP, SMTP, and FTP protocols as well as ongoing efforts based in XML to standardize various intermachine communication efforts.

The Organization for the Advancement of Structured Information Standards (OASIS)

Another major standards-setting organization is the Organization for the Advancement of Structured Information Standards (OASIS), a nonprofit, international consortium of individuals, corporations, and organizations focused on building interoperable industry specifications based on public standards such as XML and SGML. Originally known as SGML Open, OASIS has its roots in the SGML language and was a consortium of small software vendors and large customers devoted to developing guidelines for inter-operability among SGML products. As XML grew in popularity, it became obvious that OASIS’s guidance and expertise in standards setting was needed in this new era of specification proliferation.

Today, OASIS has over 170 organizational members and is focused on simplifying interbusiness communications processes for all businesses. It does this by fostering communities of interest that are concerned with solving problems in a specific domain of expertise through open discussion and debate. OASIS as an organization doesn’t set any standards or write specifications (its constituent Technical Committee members do); instead, it creates an open forum where its members can discuss market needs and direc-tions as well as recommend guidelines for product interoperability. OASIS then consoli-dates, coordinates, and disseminates this information to its member organizations for approval and adoption.

Therefore, OASIS functions more like a community rather than an official standards body, such as the W3C or the collection of technicians that represent the IETF. OASIS has a simple membership and participation model: organizations and individuals who are members can participate in the standards definition and approval process. As a result, any group of at least three OASIS members can be authorized to create a community for development of a specific industry or community specification. These groups then form the core of the Technical Committee (TC), which can result in the production of specifi-cations to be reviewed by the OASIS membership or the Internet community in general. Once a specification (known as a committee specification) is created by a TC group, at least three implementations of the specification must be created for approval of the OASIS membership. After a minimum of 10 percent of the membership has approved the specification, it becomes a formal specification under the OASIS umbrella, although users can make use of the specification before it becomes a formal OASIS standard.

In this manner, OASIS provides a central rallying point for the different types of techni-cal specifications surrounding the structured languages of XML, SGML, and HTML. OASIS has only the following goals that TCs must meet as they develop specifications:

   They should be open to all OASIS members and casual observers.

   There should be a formal audit trail of work conducted in the TC.

   The specification development and voting process will be conducted in a democratic manner.

   The process should be flexible in the way that users can utilize the specification and the deliverables that are produced.

   The efforts should be scalable and language neutral to support the widest audience possible.

Because TCs are created by OASIS members, OASIS itself doesn’t start any specifica-tion projects and doesn’t have a technical agenda of its own. However, OASIS has the most interest in XML- and SGML-based projects that foster interoperability, vertical industry convergence, and cross-industry standards. A current list, as of October 2001, of OASIS projects is provided in Table 19.3.

TABLE 19.3    OASIS Technical Committees

Governmental Bodies

Governments are also getting into the game of producing specifications for XML. This shouldn’t seem all that amazing because governmental as well as nongovernmental orga-nizations (NGOs) that are affiliated with official processes have long been in the practice of setting standards for acceptable communications. Many of these specifications are produced as a way of meeting various regulations for trade, safety, policy, or other rea-sons, rather than meeting a technological need. As a result, the specifications tend to be very rigorous and enforced.

In the XML space, two major governmental standards organizations stick out: the United Nations and the International Organization for Standardization (ISO). The United Nations (UN) has long been in the process of building specifications for facilitating inter-national commerce. The United Nations Centre for Trade Facilitation and Electronic Business, more commonly known as UN/CEFACT, is a UN-sponsored organization whose mission is to improve the ability of businesses and organizations to trade products and services in an effective and friction-free manner.

Founded in 1996, UN/CEFACT was created to respond to the rapidly changing techno-logical environment and the need to officially recognize specific contributions to the global trade network. UN/CEFACT realized that progress needed to be made in reducing the amount of cumbersome and time-consuming paperwork, formalities, and procedures encountered by small and medium-sized businesses in their day-to-day trade. In the 1970s, the UN facilitated the development of a worldwide EDI message format and has since leveraged its experience, interest, and power in helping to craft the ebXML specifi-cation in conjunction with OASIS.

The International Organization for Standardization (ISO), whose name is derived from the Greek word isos and is not an acronym, isn’t really a governmental body, but it forms the basis upon which many governmental regulations are based. ISO specifications are numbered and can cover anything from manufacturing and quality management processes, such as ISO 9001, to setting the size of metric screw threads. ISO is made up of an international federation of 140 national standards-setting bodies, and it operates in a very formal manner.

With over 12,000 standards comprising 300,000 pages of documentation, ISO develops its standards in a formal manner that aims at achieving widespread adoption and consen-sus. The standardization process is very structured, requiring specification candidates to first submit their proposals to their national standards bodies, which in turn propose these items for consideration of ISO as a whole. The process then follows a regimented series of steps for project definition, specification, and approval, requiring the consent of 75 percent of all voting members. As a result, it is no surprise that ISO standards can be several years in the making but have long-lasting effects. ISO has begun to specify XML-based standards that will surely be used for many years to come.

Of course, there are many other governmental and affiliated standards-setting organiza-tions besides UN/CEFACT and ISO. Governments will always be the best place to estab-lish a standard that can be enforced by law, regulation, and established guidelines of conduct.

Industry Consortia

Another source of standardization and technical specification is in formal groupings of vendors that share some aspect of their business in common. These consortia usually center around industry verticals, such as insurance, electronic components, and apparel, but can also be horizontal consortia, focusing on business requirements such as retail, manufacturing, and human resources. In any case, these groups are usually established to formalize the business processes and relevant standards for their industries. Technological automation and innovation forced many of these groups to come up with relevant electronic encodings for their products and services that can be shared within their industry.

A natural outgrowth of these organizations has been the development of industry-specific or horizontally applied XML-based vocabularies. Experience has shown that the vast majority of implementations of any technology will be in these vertical industries. After all, the implementation of technology in a specific industry is where the “rubber meets the road.” Businesses of all shapes and sizes fall into a number of industry classifications and types, and there is no way that a particular specification can meet the different, and often diverging, needs of these various industries.

Examples of industry consortia include the Computing Technology Industry Association (CompTIA), focusing on the electronic component and information technology indus-tries, ACORD, which solves problems for the insurance industry, and Health Level Seven (HL7), which focuses on similar problems for the healthcare industry.

Chapter 22, “Applied XML in Vertical Industry,” covers information on these vertical industry standards and specifications in considerable detail, including more detail on the ACORD and HL7 efforts.

Birds-of-a-Feather Vendor Groupings

A less formal, but nonetheless effective, grouping of organizations can be thought of as the “birds-of-a-feather” vendor grouping. Such vendors come together when a specific problem needs to be solved. In these cases, the borders and differences between different industries may be blurred as the problem that needs to be solved becomes increasingly more critical to everyone’s success. Alternatively, it just may be that a certain technologi-cal issue needs to be standardized before it can be put to use in any particular industry.

Whatever the root cause, the need to solve a given problem will motivate different orga-nizations to come together to provide a technical specification to solve the problem.

Good examples of this loose organization of companies are the SyncML and Universal Description, Discovery, and Integration (UDDI) efforts. In the case of SyncML, vendors in the various mobile, wireless, computing, and portability industries got together to pro-duce a single specification for synchronizing data between their various devices, systems, and platforms. UDDI’s main objective was to produce a practical and quickly imple-mented central repository for Web Services components and descriptions. In both cases, the groups never existed prior to this point, and may not exist in the long term. Instead, the goal to produce a specification and solve a specific need drew them together.

The main issue in these problem-centric groupings of organizations is that their longevity and ability to enforce their respective specifications beyond the initial grouping of cus-tomers is in question. Because the firms get together for a specific reason, once the rea-son has been addressed, the group’s need to exist comes into question. Another point of contention with these sorts of organizations is that they are often somewhat closed in their membership and solicitation of general feedback and scrutiny. For the firms that participate in these endeavors, their goal is to solve a problem, not serve as a standards body. Of course, in effect, these groups are standards bodies in what they are producing.

Individuals and Organizations

The final set of standards-setting and specification-creating bodies includes single com-panies and individuals. Vendors of all types of products and services are constantly being motivated to improve their products and services in a manner that is competitively advan-tageous. Many of them are looking to XML as a means for providing this capability. Some are also looking at XML as a way to provide extensibility and flexibility to their product while simultaneously providing an open API that users can interact with.

These needs are motivating the creation of single-vendor standards, which are really specifications created by large and small companies alike that have been published to the community at large for its usage. The most typical of these single-vendor standards are those published by the large software and technology companies Microsoft and Sun Microsystems. Each of these vendors has produced XML and other specifications that are being used by millions of users worldwide. Some would argue that the single-vendor standards are the ones more frequently in use, whereas some of the other consortia and standards body–driven specifications languish for years without any adoption. Of course, the major downside to this approach is that the specifications are rarely open for general review, comment, and improvement. Rather, users must rely on the vendors to continue to enhance, maintain, and document their specifications to the required level.

Also, motivated individuals have been creating XML specifications, such as ChessML, for general adoption by the general user community. These individuals are mainly moti-vated by simple needs or the desire to share their knowledge, and many of their resultant specifications are not widely adopted. Rather, they have been used to form a starting point or “straw man” proposal for the generation of specifications by larger and more well-funded standards organizations.

The Standards Stack

Given the number of specifications created by the diverse set of standards-setting and specification-creating bodies, as mentioned previously, it is important for us to

be able to identify which standards solve which set of problems and which are in possi-ble competition or conflict with each other. This categorization of standards is commonly done throughout many technology segments and usually takes the form of a visual representation model called a stack. As the visual metaphor suggests, a standards stack is much like a stack of pancakes: Each layer is a separately defined entity, but the various layers depend on each other for their technology and interoperability. The higher in the stack one goes, the more technology and specifications each layer is dependent

on or references.

One of the most common standards stacks in use is the International Standard Organization’s Open System Interconnect (ISO/OSI) network layer model. Shown in Figure 19.1, the OSI model shows how the various network protocols and technologies, such as Ethernet, TCP, and HTTP, relate to each other and compare to other specifica-tions on the stack.

The OSI network model is in frequent use by many that use or create network protocol specifications. In a similar vein, as the use and proliferation of XML specifications grow, a similar stack needs to be created. However, there is one major difference between the OSI model and the need for modeling XML specifications. Network protocols have a fairly simplistic set of dependencies. Technology at one layer depends on the technology of the lower levels. Yet, this strict layering doesn’t exist in the XML world. Rather, there are some aspects of XML specifications that exhibit layering behavior, whereas others can be applied to multiple layers in the stack. As a result, the network model has a two-part rendition that can be seen in Figure 19.2.

As shown in this figure, the standards stack consists of many portions and can be divided into four main components:

   XML base architecture

   Technology layers

   Cross-layer aspects

   Community (vertical) specifications

As will be further detailed in the later sections, these various components aim to help users identify which part of the XML standards playing field they are standing on as well as provide a different set of specifications that solve different needs.