Accommodating the Human Element

As indicated in the general principles, ebXML needs to work in a range of trading partner environments and business processes. One of the key variables , and a factor that separates ebXML from traditional EDI, is the extent of human involvement in the exchanges among companies. EDI transactions assume that the messages go from one system to another ”either directly or through a mailbox ”with no human intervention at either end. Systems based on EDI-style exchanges often have high volumes and predictable formats that allow for mapping directly out of or into the trading partner business systems.

While ebXML messages need to support these kinds of interactions, they also need to manage those with direct human involvement and intermediation. Some companies may not have the volume to support a fully integrated system that automatically generates or captures and transforms data from trading partners . In other cases, the applications may require human review, such as patient healthcare records or simple email-based message interchanges. As indicated in the general requirements, ebXML also needs to support business-to-consumer interactions, and while we can expect to see more software that fully integrates data from businesses into end- user applications, we will have plenty of human hands entering data as well.[20]

Businesses will also capture data from paper forms or need to generate paper forms according to predefined formats, and ebXML-compliant systems need to accommodate these contingencies. Trading partners may specify their own output formats, or industries may have their own standard formats, such as for descriptions of hazardous materials. In 1981, the United Nations defined a common format for paperwork used in international commerce, called the United Nations Layout Key for Trade Documents. The layouts are specifically mentioned in the ebXML requirements as an example of a standardized style sheet for paper forms that act as input for or output of business systems.[21]