3.0  WEB (XML) STANDARDS AND THE INTERNET

The "fusion" of EDI with Web technology standards is fueling the development of next generation e-businesss integration frameworks. This section is the last stop before we go on to describe the development of next generation e-businesss integration frameworks. This section focuses on "Web Technology Standards" as illustrated in the following diagram:

Figure 3.0-1  Web Technology Standards

The two main management standards management organizations for Web and Internet standards/specifications are the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). This section presents a high-level overview of the aforementioned standards management organizations and some of the key XML/EDI specs/standards for each organizations.

The next section describes the W3C and the relevant XML specifications that continue to emerge within the W3C. However, before we continue it is important to note that the three ISO standards (Figure 3.0-2) were used, in part, as the basis for the initial development of Web compatible counterpart specifications, also shown below, which are developed and maintained by the W3C.

Figure 3.0-2  Web Technology Standards

3.1  World Wide Web Consortium (W3C)
The World Wide Web Consortium is the main standards body (non-accredited) for the World-Wide Web. W3C was created by the Massachusetts Institute of Technology (MIT) during October 1994. Netscape Communications Corporation was a founding member. The Consortium is operated by MIT Laboratory for Computer Science (LCS) and The French National Institute for Research in Computer Science and Control (INRIA), in collaboration with CERN where the Web originated. W3C is funded by industrial members and with support from DARPA and the European Commission but its products are freely available to all. Organizations may apply for membership to the Consortium; individual membership isn't offered. The director is Tim Berners-Lee who invented the World-Wide Web at the Center for European Particle Research (CERN).

The W3C works with the global community to establish international standards for client and server protocols that enable on-line commerce and communications on the Internet, which include the XML specification and its complementary specifications (often referred to as the "XML Family of Standards"). The W3C also produces reference software. The various types of specifications/publications produced by the W3C are as follows:

Table 3.0-1  W3C Specifications/Publication Description

Although the W3C is the organization responsible for specifications such as HTTP, et. al., this section focuses soley on the XML. Although XML, itself, is a W3C specification, there are a family of specifications accompanying and complementing XML. Currently the following members of the XML family of specifications have been formally recommended by W3C:

1. The Extensible Markup Language (XML),
2. The Document Object Model (DOM), Level 1,
3. XSL Transformations (XSLT),
4. The XML Path Language (XPath),
5. Namespaces in XML, and
6. The Extensible HyperText Markup Language (XHTML).

Table 3.0-2  Description of XML Specifications

In addition to the formally recommended XML specifications, the following W3C specifications are currently in a working draft format:

1. Document Object Model (DOM), Level 2
2. The XML Pointer Language (XPointer)
3. The XML Linking Language (Xlink)
4. XML Schema Part 1: Structures
5. XML Schema Part 2: Datatypes
6. XML-Signature Requirements W3C Working Draft 14-October-1999
7. XML-Signature Syntax and Processing W3C Working Draft 10-May-2000

A very important area receiving great attention in the W3C is XML Schemas. The Schemas specifications should be formally recommended sometime around the 3-4 QTR 2000. Oracle is working together with IBM, Microsoft, CommerceOne, and others in the W3C XML Working Group to define an Internet Standard for "XML Schemas." This effort will create a standard to describe the data types, structure, ordering, and mapping support for a document's elements, which will enable more automated and seamless integration of XML with databases, e-commerce applications, and programming languages. It is important to note that the majority of COTS XML/EDI applications currently use some form of an XML Schemas syntax as opposed to traditional XML Document Type Definitions (DTDs). All COTS vendors have stated that they will move to support the recommended W3C XML Schemas syntax standard when it is released.

An additional W3C specification emerging with potential applicability to XML / EDI is the Resource Description Format (RDF). With the benefit of experience, RDF makes a great step forward from specifications such as HTML and HTTP. These specifications have been extended significantly during their evolution to date. The process has been one of the experimental additions of new tags. The significance or importance of new tags has never been evident to software not involved in the experiment, with resulting danger of serious incompatibility.

RDF has the goal to allow documents to be written in a mixture of old standard vocabularies and specific new experimental or proprietary vocabularies, but with well defined way of knowing what is important, what can be ignored, and how old software can deduce or download and understanding of a new vocabulary. This will hopefully allow powerful combinations of applications when, for example, documents can be made which combine in a well-defined way concepts for instance from banking, engineering and legal vocabularies. The power of the Web as an expressive medium will become the product (rather than the sum) of the individual developments. Furthermore, by allowing experimental vocabularies to intermix with standard vocabularies without threatening the integrity of the system, RDF will give a surer and faster deployment path for new ideas free from the need for so many standards meetings.

In summary, the W3C is a Web technology standards organization. The application of these Web technologies and the integration of these technologies into standard frameworks is what we see occurring within various industry consortia standards organizations, which is discussed in the next section.

3.2  Internet Engineering Task Force (IETF)
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. The IETF has been in existence much longer than the W3C and it is open to any interested individual. The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year. Much of the work of the IETF involves messaging and communications transport of the

The IETF working groups are grouped into areas, and managed by Area Directors, or ADs. The ADs are members of the Internet Engineering Steering Group (IESG). Providing architectural oversight is the Internet Architecture Board, (IAB). The IAB also adjudicates appeals when someone complains that the IESG has failed. The IAB and IESG are chartered by the Internet Society (ISOC) for these purposes. The General Area Director also serves as the chair of the IESG and of the IETF, and is an ex-officio member of the IAB.

One of the working groups of the IETF is called EDIINT, which is addressing Electronic Data Interchange-Internet Integration. The initial request for comment Request For Comment (RFC) 1767 defined the method for packaging the EDI X12 and UN/EDIFACT transactions sets in a MIME envelope. However, several additional requirements for obtaining multi-vendor, inter-operable service, over and above how the EDI transactions are packaged, have come to light since the effort concluded. These currently revolve around security issues such as EDI transaction integrity, privacy and non-repudiation in various forms. Additional requirements that mimic many of the heading fields found in X.435 EDI messages (e.g., Interchange Sender, Interchange Recipient, interchange Control Reference, Communications Agreement ID, and Syntax Identifier) are also needed to support exchanges by point-to-point, FTP and SMTP protocols. Many believe these heading fields are best described in XML. Standards in these and other areas are necessary to ensure inter-operability between EDI packages over Internet. Various technologies already exist for these additional features and the primary requirement is to review and select a common set of components for use by the EDI community when it sends EDI over the Internet. In effect, the effort is to provide an EDI over the Internet Informational and Applicability Statement Documents. The ebXML initiative is borrowing on the lessons learned from this effort in their transport, routing, and packaging-working group (see ebXML Section 4 of this document).

A very important area receiving a lot of attention in both the W3C and IETF is XML Digital Signatures. According to their charter, the XML Signature Working Group is tasked with developing "an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages [anything referencable by a Uniform Resource Identifier (URI)] and procedures for computing and verifying such signatures." This is a joint effort between the IETF and the W3C. The current schedule for the XML Signature Working Group shows that the "Signature Syntax and Processing Specification" will be submitted in July 2000 for W3C Recommendation.

To date the working group has two major documents and many supporting documents on its website (http://www.w3.org/Signature/Overview.html). The Core Syntax document dated May 10, 2000, titled XML-Signature Syntax and Processing (http://www.w3.org/TR/2000/WD-xmldsig-core-20000510/), specifies the syntax and processing rules for the encoding of digital signatures using XML. Such signatures can provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or locatable elsewhere." The Requirements Document, dated October 10, 1999, "lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination."

The specification dictates an XML tagset structure that defines the components of the signature and their occurrences (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences). The following structure has been defined by the working group by both DTD's and XML-Schema.

<Signature>

<SignedInfo>
(CanonicalizationMethod)?
(SignatureMethod)
<Reference (URI=)? >

(Transforms)?
(DigestMethod)
(DigestValue)

</Reference>)+
</SignedInfo>
(SignatureValue)
(KeyInfo)?
(Object)*

</Signature>

Signature - Root Element.
CanonicalizationMethod - Specifies canonicalization algorithm applied to the SignedInfo element prior to performing signature calculations.
SignatureMethod - specifies the algorithm used for signature generation and validation. This algorithm identifies all cryptographic functions involved in the signature operation (e.g., hashing, public key algorithms, MACs, padding, etc.).
Reference - specifies a digest algorithm and digest value, and optionally an identifier of the object being signed, the type of the object, and/or a list of transforms to be applied prior to digesting.
Transforms - contains an ordered list of Transform elements; these describe how the signer obtained the data object that was digested.
DigestMethod - identifies the digest algorithm to be applied to the signed object.
DigestValue - contains the encoded (base64) value of the digest.
KeyInfo - It enables the recipient(s) to obtain the key(s) needed to validate the signature and contains keys, names, certificates and other public key management information, such as in-band key distribution or key agreement data.