The concept of the Electronic Enterprise requires a transition away from paper form based EDI. Key concepts that are required are the encapsulation of agreed sets of business rules (in EDI parlance the Implementation Guidelines) and also mechanisms to handle state and flow control (such as those provided by hyperlink anchors in HTML files). Also message sets must be able to handle partial information, where the complete information is not yet available, or simply is not required for the particular business process. This allows different parts of an enterprise to selectively contribute only the information that is germane to their business functions.

A fundemental difference between the proposals in these XML/EDI Guidelines and those found in other proposals for XML-based web retailing, such as those covered in the Open Trading Protocol (OTP), is the client-centric nature of the business processes, as contrasted with the server-centric nature of electronic retailing. To distinguish these two terms, we use the term "Electronic Business" to refer to the processes of fulfilling customer requirements through the application of negotiated business processes leading to the supply of manufactured goods to retailers and service providers, and "Web Commerce" to describe the process of selling manufactured goods to consumers.

Electronic business is client-centric in that is starts with a specification of a client's requirements, rather than a statement of what the supplier has to offer. The specification of requirements gets sent to a number of potential suppliers, who are asked to tender for the business by a predefined date/time. The purchaser is, as a result of this process, provided with more than one choice, and must determine which quotation to accept. This may require a period of contract negotiation to ensure that adequate terms and conditions, including delivery criteria, are met. This may require a looping of the processes, with a need to cross-refer between successive documents.

Once the purchaser has selected a supplier the business processes involved are very similar to those involved in web commerce, but there are subtle differences. For example, electronic payment before delivery is unlikely to be required for electronic business transactions. Instead of being an integral part of the negotiation phase, with payment being made at the time the order is placed, payment in the electronic business scenario is a separate process that occurs immediately after delivery. This introduces concepts such as statements, which do not occur in web commerce scenarios.

XML is the Extensible Markup Language subset of ISO's Standard Generalized Markup Language (SGML) developed by the World Wide Web Consortium (W3C) SGML on the Web working party during the latter half of 1996 and early 1997. The formal recommendation was submitted for approval by W3C members on 8th December 1997.

On 10th September 1997 a proposal for a new form of XML Style Language (XSL), which incorporates the ECMAScript standardized variant of JavaScript, was published by a consortium led by Microsoft, ArborText and the Inso Corporation. This version of the XML/EDI specification uses the power provided by this new advanced language combination to show how control of XML/EDI document processes can be achieved in a distributed manner.

In October 1997 a specification for a formal Document Object Model (DOM) for XML documents was published by W3C. This model provides a standardized API for XML-based tools.

Combining XML and EDI to develop XML/EDI suggests that the main method of capturing and coding EDI information will be through XML-coded electronic forms. At present the form handling characteristics of XML are yet to be fully agreed (agreement is expected during 1998). To allow interaction with existing sytems the XML/EDI Guidelines show how EDIFACT messages can be generated from XML/EDI forms, and vice versa.

XML/EDI isn't creating a new standard. XML/EDI is defining how companies can use current standards to solve their business problems.

Electronic Data Interchange (EDI) has been used for business-to-business communication for almost a quarter of a century. Initial efforts involved inter-company agreements on how to exchange commercial data, initially as information stored on tape and later as messages sent over dedicated data lines. To avoid having to use different protocols to move data between different companies, various industry groups identified sets of data that could form the basis of individual agreements. The industry groups also sought to agree the format in which fields in such data sets were interchange so that a company only needed to develop one methodology for decoding information received without resource to human intervention.

The Achilles Heel for this approach has always been two fold. Firstly, companies require flexibility in, and wish to deviate from, doctrinaire standards that do not fully meet their business needs. Secondly, because the standards are pre-ordained there is no mechanism provided to transfer processing rules and associated information. It is assumed that the data meets the defined constraints and if not, has been duly modified to conform. This means that companies must conduct exacting analysis to determine precisely how they are going to move their business data to and from the predefined EDI formats. The cost of these constraints has been borne as excessively long and complex implementation cycles for traditional EDI systems.

The world has changed from thirty years ago, and now requires more dynamic and vibrant services that match the organized yet ad hoc nature presented by both modern business practice, and particularly its manifestations on the Internet. The Internet is re-writing the rules on how people interact, buy and sell, and exchange goods and services. In particular the Internet is showing us that EDI is not only relevant for business-to-business communications. The same concepts are also relevant for all consumer-to-supplier relationships, whether the consumer is an end-user, a manufacturer, a service organization such as a hospital or a hotel, a governmental organization or a virtual organization.

With the arrival of the Internet in the last decade of the 20th century the pattern of electronic commerce has dramatically changed. In particular, the Internet has introduced many new ways of trading, allowing interaction between groups that previously could not economically afford to trade with one another.

Whereas previously commercial data interchange involved mainly the movement of data fields from one computer to another, without human intervention, the new model for web-based commerce introduced by the Internet is typically dependent on human interaction for the transaction to take place. The new model is based principally on the use of interactive selection of a set of options, and on the completion of "electronic forms", to specify user requirements.

As this new model develops there has been a fundamental shift in how data used for commerce should be processed. The original create-->transmit-->receive-->process cycle of information processing, using individual programs, is beginning to be replaced by the concept of active objects which have inherent processes associated with them, based on the class of information they contain. Today an invoice may no longer contain a copy of the information stored in the database it was generated from: instead it contains a pointer that says where it expects to get the data from, and this data will be fetched from its managed source each time the invoice is processed.

Such interactive programs require us to review the underlying philosophy of electronic commerce. What are the characteristics of a system designed for "electronic business transactions" in an international marketplace?

To be truly interactive you need to be able to: Understand the business concepts represented in the interchanged data. Apply business-specific rules to the interchanged data to identify what class(es) of data it contains and formulate appropriate responses.

To do this you need to be able to: identify the role and syntax of each piece of interchanged data identify the source of each shared piece of information identify which pieces of information should occur in each interchanged set of data and, if relevant, the order in which they occur in a particular message stream identify who is responsible for creating, transmitting, receiving and processing each message, and which programs should be used to control each of these processes identify when a message should be moved from one stage of the interchange process to another identify which rules should be used to check that the relevant forms of interchange have taken place and to move data from one presentation template to another.

Because these interactions can be complex, and potentially require specialized knowledge, the rule templates can be supplemented by XML/EDI data manipulation agents (DataBots) to ensure that users can express their requirements in high-level, natural language, terms. DataBots automatically create appropriate rule templates and XML syntax to match user requirements and broker the entire interchange.

When DataBots are being used XML/EDI is identified as being robot generated by adding an R to its name to become XML/EDI-R.

At this point in time the ECMAScript subset of the Java programming language provides the vehicle that permits the DataBots to be deployed and received along with XML/EDI messages.

XML will be native language for the next generation of most of the popular WWW browsers. XML/EDI seeks to leverage the work and support (technically and financially) which XML is receiving. With traditional EDI, the infrastructure was built from the ground up, without being able to share resources with other programs. This paradigm is no longer appropriate in today's world of shared software development. By adopting XML/EDI, the EDI community can get to share the cost of extension and future development.

In 1986 the International Organization for Standardization (ISO) published an international standard defining a Standard Generalized Markup Language (SGML) that allowed its users to: identify the role and syntax of each piece of data in an interchanged document identify which pieces of information should occur in each interchanged set of data and, if relevant, the order in which each such element should occur in a particular document identify which programs should be used to control each of these processes.

SGML has formed the basis of many of the large, multinational, documentation projects that have developed in the decade since its publication. It also formed the basis for the formalization of the HyperText Markup Language (HTML) that led to the formation of the World Wide Web of documentation that has become available on the Internet.

Key to the success of HTML was the development of the concept of Uniform Resource Locators (URLs) that allow users to identify the source of each piece of shared data in a consistent manner. Whilst the original concept has limitations as to the granularity of data access, its universality has greatly improved computer-to-computer communications.

In July 1996 the World Wide Web Consortium (W3C) set up a working group to study how SGML could be simplified to allow for its efficient use over the Internet. The result was the development of an Extensible Markup Language (XML) that combined the expressive power of SGML with the Internet-aware functionality of HTML.

XML provides an ideal methodology for electronic business because: XML allows message type creators to clearly identify the role and syntax of each piece of interchanged data using a definition that is both machine processable and human interpretable XML allows message type creators to identify the source of each shared structure using an Internet Uniform Resource Locator XML allows message type creators to optionally identify which pieces of information should occur in each interchanged set of data and, where relevant, the order in which individual fields should occur in a particular message stream XML documents can be given metadata fields that can be used to identify who is responsible for creating, transmitting, receiving and processing each message, and can have built-in facilities for identifying the storage points of programs that should be used to control processes XML can make use of facilities provided by the latest version of the Internet HyperText Transfer Protocol (HTTP), which can identify when a message should be moved from one stage of the interchange process to another, and to check that the relevant forms of interchange have taken place.

XML can be integrated with existing EDI systems by: providing application-specific forms that users can complete to generate EDI messages generating EDI message formats for transmission between computers over the Internet, or through existing value-added networks (VANs) allowing data received in EDI format to be interpreted according to sets of predefined rules for display by the receiver on standardized browsers using a user-defined template, rather than having to rely on specially customized display packages.

XML can extend existing EDI applications by: allowing message creators to add application-specific data to standardized message sets where required allowing message creators or receivers to display the contents of each field in conjunction with explanatory material which is specific to the application and the language preferences of the user allowing system developers to customize the help information associated with the data for each field allowing field value checking to be integrated with checks on the validity of the data with respect to information stored on local databases.

The following examples of the type of facilities that could be built into an XML/EDI implementation isn't comprehensive, but a starting place for discussion: Lexicon Repositories (holding EDIFACT, X12, or BSI dictionaries, DTDs and common business objects) XML/EDI Data Manipulation Agents (DataBots) - which enable rule-driven processing XML/EDI Business Objects (predefined object processors identified by XSL scripts) XML/EDItors used for the creation and completion of form-based EDI messages XML/EDI extensions for message stores Search Agents which recognize XML/EDI specific tagging and are able to request data from both private and public message stores (e.g. through Web interfacing) Trading Partner Pages - extensions of "yellow pages", but with verified integrity of characteristics.

Each of these options is explained in more detail in the following subsections.

The following stages are involved in using XML for the interchange of commercial EDI messages: identification of suitable data sets for electronic business transactions development of XML document type definitions (DTDs) that formally define the relationships of the fields that are to form a particular class of EDI messages the definition of application-specific extensions to standard message types the creation of instances of specific types of electronic business message the validation of the contents of messages the transmission and receipt of electronic business messages the processing of electronic business messages using DataBots.

An application does not need to use all of the levels of processing shown in Figure 1 and the above list: it can stop at whichever level in the hierarchy suits it. For example, an application can confine itself to checking incoming and outgoing EDI messages using a document object model that has been formally defined in an XML DTD.

Identification of data sets for electronic business transactions will often be the responsibility of industry associations and various standardization bodies such as UN/EDIFACT and EBES (the European Board for EDI standardization).

Whereas existing EDI definitions are primarily concerned with the way in which a set of fields forms a message, the concepts required for XML/EDI are based more on the definition of independent classes of information that can be combined together with other classes of information to form interchangeable messages. As such the concepts are more akin to the idea of a Basic Semantic Repository (BSR) being proposed by ISO, and of the Business Systems Interconnection (BSI) proposal from University of Melbourne.

There is, however, one basic difference between using XML/EDI for defining data classes and using the BSR or BSI methodologies. In XML/EDI the order and number of subclasses of a data class can be altered by message creators without having to formally register that fact with any centralized organization. For example, if it was necessary for an application to separate building numbers or names from information about the street the building is located within, XML/EDI would allow system developers to define two new subclasses that would be combined to provide the information needed for an existing EDI address component.

One of the advantages the accrues from XML/EDI's ability to subclass fields is that such fields can be developed interactively using information supplied from more than one location. For example, telephone order processing systems in today's world of electronic business transactions often start by asking users for their postcode. This tells the system which region, town and street the user is located in, but not which building they are in. To find this out you need to ask the user for a number or name that uniquely identifies the building within the street identified by the postcode. Using these two related pieces of information it is possible to interactively complete a standardized class of information, an address, that can then be shared by an order, its delivery note, and the invoice required for settlement.

Once information has been captured once, and used to create an instance of the relevant class of data, it should not be necessary to recreate the information each time it is required. All that should be needed is that business processes that need this information reference the point at which the data was originally captured, e.g. the address associated with the order for the goods.

An essential precursor to the design process of an XML/EDI application is a study of how business processes re-utilize stored information. Where suitable business models already exist, these can be represented in XML form. Where there are no existing model, or the existing models do not meet the requirements of the trading partners for some reason, developers should perform a full analysis of the relevant business processes, and seek to identify similarities between these processes and those already formally documented for use by other applications. Knowledge of the source and contents of public repositories of resusable data segments will help to simplify this process. One of the goals of XML/EDI, therefore is to encourage the setting up of such repositories of knowledge.

To ensure that users can guarantee the long-term maintenance of data set components repositories of formal XML definitions will need to be created, and unique object identifiers will need to be assigned to each set of components. While initially testing can be done using system identifiers that resolve to Internet Unique Resource Locators (URLs), in the longer term a mechanism for identifying shared data sets using formally registered SGML public identifiers associated with URLs will need to be developed. A system for resolving public identifiers to obtain copies of the registered definitions will also be required.

Messages that pass between systems will typically conform to a previously agreed XML document type definition (DTD) that formally describes, in terms interpretable by both humans and computers, an internationally accepted message type.

Note: The structure of XML DTDs and document instances is formally defined in Extensible Markup Language (XML). A bried introduction to the components of XML can be found in An Introduction to the Extensible Markup Language. More complete information on the the structure of SGML DTDs, including those that implement the Web SGML extensions, can be found in Web SGML and HTML 4.0 Explained, which contains examples of the use of each of the constructs used in SGML and XML, and explains how these facilities are used within HTML.

XML DTDs can be developed by: international standards bodies wishing to develop standardized sets of interchangeable data industry associations wishing to develop agreed procedures for interchanging messages between members one of the members of a multilateral or bilateral agreement to share information a company wishing to supply information to a number of suppliers or customers a company wishing to obtain information in a known format from a number of suppliers or customers.

Declarations that form a standardized XML DTD will typically be stored in separate files, which can be referenced, as an XML external subset, by those wishing to use it through the Internet Uniform Resource Locator that its originator has assigned to a publicly available copy of the data. Alternatively, if public access is to be restricted, the document type definition can be stored as the internal subset within the document type definition sent with the message.

Where the document type definition is based on classes of information shared by more than one message, each class of information can be defined in a separate file, known in XML as an external entity, these files being referenced in a suitable sequence from within the external or internal subset of the XML DTD.

For example, an XML DTD could have the form: <!ENTITY % address SYSTEM "http://www.myco.org/messages/XML/address.xml" > <!ENTITY % items SYSTEM "http://www.edifact.org/messages/XML/items.xml"> <!ENTITY % data "(#PCDATA)"> <!ELEMENT order (order-no, deliver-to, invoice-to, item+) > <!ELEMENT order-no %data; > <!ELEMENT deliver-to (address) > <!ELEMENT invoice-to (address) > <!--Import standard address class--> %address; <!--Import standard item class--> %items;

This DTD fragment defines two external and one internal parameter entity, four locally defined elements and contains two parameter entity references (%address; and %items;) that call in the contents of the external entities at appropriate points in the definition. Both of the parameter entity references are preceded by explanatory comments.

Note that the source of each class of information is identified not in the call to the class itself (%address;) but within a formal definition of the data storage entities required to process the class definition references (e.g. the first two lines of the DTD). This technique allows files to be moved without having to change the main definition of the DTD.

Typically the entity definitions will be stored outside the DTD, which will contain a reference to the URL of the point at which the latest details of library file locations can be found. For example: <!ENTITY % library SYSTEM "http://www.myco.org/messages/XML/library.ent"> %library; <!ELEMENT order (order-no, deliver-to, invoice-to, item+) > <!ELEMENT order-no %data; > <!ELEMENT deliver-to (address) > <!ELEMENT invoice-to (address) > <!--Import standard address class--> %address; <!--Import standard item class--> %items;

where %library; references a file containing the entity definitions given at the start of the previous example.

XML provides (experimental) facilities for ensuring that data modules taken from libraries do not introduce name clashes in their elements. The names of elements within each module can be qualified by a module (namespace) identifier. Each namespace identifier can be associated with a URL that uniquely identifies where the module is formally defined. For example, the contents of the library file referenced above could be defined as: <?xml-namespace href="http://www.ebes.org/XML/EDI-address.xml" as="address"?> <?xml-namespace href="http://www.ean-fora.org/XML/order-items.xml" as="items"?> <!ENTITY % data "(#PCDATA)"> <!ENTITY % address " <!ELEMENT address (address:company, address:street, address:town, address:region, address:postcode) > <!ATTLIST address id ID #IMPliED > <!ELEMENT address:company %data; > <!ELEMENT address:street %data; > <!ELEMENT address:town %data; > <!ELEMENT address:region %data; > <!ELEMENT address:postcode %data; > <!ELEMENT same-as emPTY> <!ATTLIST same-as idref IDREF #REQUIRED > "> <!ENTITY % items " <!ELEMENT item (item:identifier, item:name, item:quantity)> <!ELEMENT item:identifier %data; > <!ELEMENT item:name %data; > <!ELEMENT item:quantity %data; > ">

XML permits entities and attributes that are defined in the external subset to be redefined in the internal subset. This facility allows XML/EDI users to develop locally significant subclasses. It can also be used to create subsets of messages by removing unused fields from the data model.

For example, the internal subset of a DTD based on the above standardized DTD could contain the following local redefinition for the %items; parameter entity: <!ENTITY % items " <!ELEMENT item (item:identifier, item:name, item:quantity)> <!ELEMENT item:identifier (item:database-key?, item:EAN) > <!ELEMENT item:database-key %data; > <!ELEMENT item:EAN %data; > <!ELEMENT item:name %data; > <!ELEMENT item:quantity %data; > ">

In this case the optional item:database-key field could contain a direct pointer to the database entry from which the EAN and associated product name were obtained. This key could be used by a DataBot to process the item information without having to generate a query based on the EAN normally provided by the identifier field as the basis for a slower-to-process database query.

An XML/EDI electronic business message consists of a pointer to the document type definition, any definitions required in the internal subset of the DTD, and entries for each of the fields required for the message. For example, the following document type declaration could be used to extend the external DTD shown in the first of the examples shown above, which is identified by its Internet Unique Resource Locator: <!DOCTYPE order SYSTEM "http://www.myco.org/messages/XML/message1.xml" [ <!ENTITY % items " <!ELEMENT item (item:identifier, item:name, item:quantity)> <!ELEMENT item:identifier (item:database-key?, item:EAN) > <!ELEMENT item:database-key %data; > <!ELEMENT item:EAN %data; > <!ELEMENT item:name %data; > <!ELEMENT item:quantity %data; > "> ]> <order> <order-no>123456 </order-no> <deliver-to> <address id="SGML154"> <address:company>The SGML Centre </address:company> <address:street>29 Oldbury Orchard </address:street> <address:town>Churchdown </address:town> <address:region>Glos. </address:region> <address:postcode>GL3 2PU </address:postcode> </address> </deliver-to> <invoice-to> <same-as idref="SMGL154"/> </invoice-to> <item> <item:identifier> <item:database-key>key151235 </item:database-key> <item:EAN>15356378797 </item:EAN> </item:identifier> <item:name>Special Offer 16 </item:name> <item:quantity>12 </item:quantity> </item> </order>

Note that, because of the prioritization SGML gives to local definitions, the definition for the %items; parameter entity provided in the local subset will replace the reference to the external source for the same entity provided as part of the file referenced using the external subset.

XML/EDI messages can be validated by a validating XML document instance processor (known as an XML parser) to ensure they contain all required elements from the specified data set, and that the fields are in the required sequence. When the document is found to be valid the parser can generate a document tree that conforms to the rules laid down in the Document Object Model (DOM) specification that provides a standardized API between XML parsers and browsers and other forms of program.

XML elements can be assigned attributes that point to processors that can undertake relevant data validity checks. This can be done either by associating notation processors with an element, or by associating an ECMAScript specification with the element as part of an XSL "action" associated with the specific element types used in specific contexts, or with particular attribute values.

Where the XML Style Language (XSL) is not being used (e.g. because the browser does not yet support it) the basic XML language allows user-defined notation processors to be used to validate the contents of specific XML elements. This is done by adding definitions of the following form to the external or internal subset of the DTD: <!NOTATION EAN-vailidator SYSTEM "http://www.myco.org/messages/validate/EAN.cgi"> ... <!ATTLIST EAN check NOTATION (EAN-validator) #FIXED "EAN-validator">

The predefined check attribute of the EAN element will cause the contents of the element to be passed to the program identified by the declaration for the notation assigned the local name EAN-validator which is stored at the location indicated by the URL given in the notation declaration. This processor would typically pass back a message indicating whether or not the EAN is valid within the context of the relevant message.

XSL provides an alternative, and more generally applicable method that allows ECMAScript to be used to validate the contents of XML elements. Details of this method are given below under the heading "Processing messages".

Note: In December 1997 an extension to SGML allowed typed data attributes to be used in standard SGML files. As soon as this new functionality is absorbed into XML it will be possible to greatly simplify the validation of message contents.

Data captured in XML/EDI messages can be exchanged: in the form of an XML file (which can be encoded in any way required, but would normally be transmitted using the UTF-8 encoding of the UCS-2 data set by default) interchanged using the HTTP protocol, or one of its derivatives (e.g. Secure HTTP) in the form of a multipart Internet e-mail message (MIME or Secure MIME encoded) in the form of a zipped (or otherwise encoded) file transferred using the Internet File Transfer Protocol (FTP) as a compressed (but not otherwise encrypted) set of extensions to an HTTP POST message that conforms to Internet's Common Gateway Interface (CGI) specification in the form of an EDI message (created by processing the XML file at source using a special conversion program).

Where conversion into a known EDIFACT format is required the DTD can be extended to provide additional attributes that can guide the transformation process. For example, the following additional properties could be added to the list of attributes assigned to the EAN element: <!ATTLIST EAN check NOTATION (EAN-validator) #FIXED "EAN-validator" EDI-prefix CDATA #FIXED "liN+1++" EDI-suffix CDATA #FIXED ":EN'" >

Messages exchanged as XML/EDI files can be re-validated on receipt by running them through an XML/EDI validating parser. Where messages have been converted into non-XML files prior to transmission the conversion should be reversed to allow re-validation of the received message.

During re-validation any linked parts of messages should be retrieved to ensure that the full contents of the message have been checked. When re-validation has been confirmed the Document Object Model created as part of the validation process can be used to create an auditable copy of the received message in a message store/database.

The way in which a received message would be processed would depend on which of the available methods for exchanging messages was chosen. If the message was received in a format that provided the XML/EDI message generated by the originator, the XML Style Language (XSL) can be used to associate different processes with individual element classes so that elements can be processed by one or more local processors.

XML/EDI message instances are specifically designed to make the selection of data fields and classes at the receiver as easy as possible. Each field starts with a "start-tag" that clearly identifies the class (element type in SGML/XML parlance) of the following data or embedded subelement set, and specifies any non-default properties to be associated with the data. The end of each data element is clearly identified by an "end-tag", which consists of the name of the element (class) preceded by a slash between a matched pair of outward pointing angle brackets. Fields that contain no data, and no embedded subelements, (e.g. fields that are only present to point to other data sources) have the slash indicating their end point immediately before the last angle bracket of the start-tag rather than immediately after the first one of the end-tag. (See the example for the <same-as/> element above.) Classes that contain subclasses of information have embedded elements between their start-tag and end-tag.

XSL allows sets of actions to be associated with particular XML elements. Actions can be defined in terms of values to be assigned to a set of data presentation attributes (styles), or in terms of a data processing script that users can define using a define-script object . XSL scripts are defined using the ECMAScript language used for exchanging Java programming modules.

Which actions are associated with which elements can be defined using XML element sets known as XSL rules. A simplified set of style-rules allow presentation properties to be applied to element classes. Rules can be associated with elements that have been assigned a unique identifier (id) attribute or that have been assigned a particular value for a class attribute.

Sets of rules and actions can be defined in macros. Macros can be associated with style processing attributes associated with specific instances of an element. The default set of style properties defined in XSL can be extended using define-style objects

The component parts of an XML Style Sheet can be: defined in separate file(s) referenced using Internet URLs associated with the definition of elements in the DTD appended as a header to the document instance, or associated with a specific instance of an element.

A typical XML/EDI XSL description will contain: a <define-script> element that contains ECMAScript definitions of the variables and functions required to process the document (in addition to the default function set provided by XSL) a set of <define-macro> elements that provide named sets of predefined actions a set of <define-style> elements that define properties that are to be used to control style processing a set of <rule> elements that contain within them: a <target-element> that indicates which type of element the rule is to apply to, or an <id> element that identifies the unique identifier of the particular instance of an element the rule applies to, or a <class> element that identifies which class of elements the rule is to apply to an <element> element that defines ancestors and descendants of the targeted element that must be present for the rule to apply (ancestors are dsfined by <element> elements that surround the targeted element definition, descendants are defined by <element> elements nested within the definition of the target element) an <attribute> element that identifies which attributes the selected element(s) must have before the rule applies an <invoke-macro> element, which may have embedded within it a set of <arg> (argument) control elements, that indicates which macros are to be associated with the rule a set of actions that must be processed/evaluated when the rule pattern is matched a set of <style-rule> elements that show which presentation styles should be associated with particular element types/classes/instances.

XSL actions are typically associated with the way in which objects should be presented to users. This process is typically controlled through the use of flow objects. XSL provides two default sets of flow objects, one based on the elements typically found in HTML files, and the other based on the flow objects defined in ISO/IEC 10179 (DSSSL). The set of DSSSL flow objects supported by XSL includes: scroll - used for control of scrollable screen displays paragraph - used to create blocks of text line-field - used to control the presentation of lists table, together with associated controls for table-part, table-column, table-row, table-cell and table-border - used to control the presentation of tables simple-page-sequence - used for creating multi-page documents sequence - used for specifying inherited characteristics link - used to control the presentation of hypertext links.

The <eval> element can be used to indicate points at which macros and scripts are to be evaluated as a result of applying a rule.

For an example of the use of XSL specifications based on the use of HTML flow objects refer to Appendix A.

The XML link process can be used to associate XML/EDI rules with a file. Normally the Simple link format will be used to identify one or more files containing the relevant rules. Typically this will result in a processing instruction of the following form being added to the start of the document instance: <?xml-edi-rules-template HREF="http://www.myco.org/XML/EDI/Rules/orders.xml"?>

The form shown in Figure A.1 has been designed for displaying a book order based on the EDItEUR Book Ordering Message as described in the EDItEUR EDI Implementation Guidelines for Book Trade Distribution.

Note: The use of form fields in the following table is gratuitous: it is intended to indicate that user interaction with XML displays is possible. The form was produced using beta software for an add-on to Internet Explorer 4.0 (MSXSL) released by Microsoft in January 1998 to demonstrate the power of their XML Scripting Language (XSL) proposal.

Figure A.2 shows how XML is used to code a form in Figure A.1. <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <?xml-stylesheet href="edi-lite.xsl" type="text/xsl"> <!DOCTYPE Book-Order SYSTEM "edi-lite.dtd"> <Book-Order Supplier="4012345000951" Send-to="mailto:orders@sgml.u-net.com"> <Title>EDItEUR lite-EDI Book Ordering </Title> <Order-No>967634 </Order-No> <Message-Date>19990308 </Message-Date> <Buyer-EAN>5412345000176 </Buyer-EAN> <Order-line Reference-No="0528835"> <ISBN>0201403943 </ISBN> <Author-Title>Bryan, Martin/SGML and HTML Explained </Author-Title> <Quantity>1 </Quantity> </Order-line> <Order-line Reference-No="0528836"> <ISBN>0856674427 </ISBN> <Author-Title>light, Richard/Presenting XML </Author-Title> <Quantity>1 </Quantity> </Order-line> </Book-Order>

Figure A.2: XML encoding of Book Order Message

A typical reaction to comparing this file with the displayed example and its EDI-based EDItEUR equivaent is "Where has all the EDI information gone?", and "Where has all the material under the table come from?". The answer is that all immutable information goes into the document type definition (DTD) referenced in the <!DOCTYPE statement that starts the coding, or in the associated style sheet.

Note: The beta release of MSXSL does not support the xml-stylesheet processing instruction, and requires the use of another technique to associate the stylesheet with the document instance.

Figure A.3 shows the contents of the DTD used for this example. The single line reference to this DTD is sufficient to provide the browser with all the additional information it needs to process the message.

Note how the definition of each element defined in Figure A.3 contains attributes whose fixed values contain the prefixes and suffixes of each of the EDIFACT fields that may need to be generated in response to the messages.

The message format generated from the completed form could be a pure EDIFACT message of the type shown on Page II-2-2 of the EDItEUR EDI Implementation Guidelines for Book Trade Distribution.

Note: The beta release MSXSL add-on to Internet Explorer 4.0 is only capable of submitting form data in the form of an HTTP's Common Gateway Interchange (GCI) message format. Conversion to EDI format would require additional program modules, which are not shown in this simple example. <!DOCTYPE Book-Order [ <!--XML-conformant Document Type Defintion for EDItEUR Book Order Message. Version 1.1 - Created January 1998 by M. Bryan from The SGML Centre This DTD should be referenced using the following public identifier: PUBliC "-//EDItEUR//DTD Book Order Message//EN" --> <!--Entities referenced within DTD--> <!--Entities used to datatype attribute values--> <!--Uniform Resource Locator identifier. Contents of attribute must provide a valid HTTP or MAILTO address conforming to IETF RFC 822--> <!ENTITY % URL "CDATA" > <!--EAN location code. Number that uniquely identifies suppliers/purchasers. --> <!ENTITY % EAN "NUMBER"> <!--Formal EDIFACT definition of datatype. May be used by EDI-compliant browsers to validate the data entered by users prior to acceptance when a user attempts to move to another field. --> <!ENTITY % EDItype "NAME" > <!--Message Content element declarations--> <!--Book Order element: Purpose: Container for message fields and support information. Attributes: EDI-Prefix formally identifies type of message. EDI-Suffix contains strings to be output at end of message. Send-to identifies Uniform Reference Locator (URL) for site to which EDIFACT message is to be sent for processing. Supplier contains unique EAN that identifies supplier. --> <!ELEMENT Book-Order (Title?, Order-No, Message-Date, Buyer-EAN, Order-line+) > <!ATTLIST Book-Order EDI-Prefix CDATA #FIXED "UNH+ME00579+ORDERS:D:93A:UN:EAN007" EDI-Suffix CDATA #FIXED "UNS+S'CNT+2:2'UNT+18+ME00579" Send-to %URL; #REQUIRED Supplier %EAN; #REQUIRED > <!--Title element: Purpose: Used to provide supplier dependent title for form: Title can be displayed in window header or at top of form, or in both locations --> <!ELEMENT Title (#PCDATA) > <!--Order Number element: Purpose: Allows users to assign unique number to their order. Attributes: EDI-Prefix formally identifies type of message. Datatype identifies format that contents must conform to. Size indicates width of box to be used to capture input. Title indicates text to precede box. --> <!ELEMENT Order-No (#PCDATA) > <!ATTLIST Order-No EDI-Prefix CDATA #FIXED "BGM+220+" Datatype %EDItype; #FIXED "C8" Size NUMBER #FIXED "8" Title CDATA "Book Order No:" > <!--Message Date element: Purpose: To indicate date order was placed. Date must be entered in ISO 8601 format without separators, e.g. CCYYMMDD Attributes: EDI-Prefix formally identifies type of message. EDI-Suffix identifies data to immediately follow contents. Datatype identifies format that contents must conform to. Size indicates width of box to be used to capture input. Title indicates text to precede input field. Comment contains explanatory text to follow the input field. --> <!ELEMENT Message-Date (#PCDATA) > <!ATTLIST Message-Date EDI-Prefix CDATA #FIXED "DTM+137+" EDI-Suffix CDATA #FIXED ":102" Datatype %EDItype; #FIXED "Date" Size NUMBER #FIXED "12" Title CDATA "Message Date:" Comment CDATA "Enter dates in CCYYMMDD format" > <!--Buyer EAN identifier element: Purpose: To identify the unique EAN assigned to the purchaser. Attributes: EDI-Prefix formally identifies type of message. EDI-Suffix identifies data to immediately follow contents. Datatype identifies format that contents must conform to. Size indicates width of box to be used to capture input. Title indicates text to precede box. --> <!ELEMENT Buyer-EAN (#PCDATA) > <!ATTLIST Buyer-EAN EDI-Prefix CDATA #FIXED "NAD+BY+" EDI-Suffix CDATA #FIXED "::9" Datatype %EDItype; #FIXED "C13" Size NUMBER #FIXED "13" Title CDATA "Buyer EAN:" > <!--Order line element: Purpose: Container for objects used to order book. Attributes: EDI-Prefix formally identifies type of message. line-no is calculated by system to be 1 + number of preceding order lines within file. Ref-Prefix identifies EDI prefix for reference number Reference-no uniquely identifies each line. Number is supplied by supplier's system with input file. --> <!ELEMENT Order-line (ISBN, Author-Title, Quantity) > <!ATTLIST Order-line EDI-Prefix CDATA #FIXED "liN+" line-no NUMBER #IMPliED Ref-Prefix CDATA #FIXED "#RFF+item:" Reference-No NUMBER #REQUIRED > <!--ISBN element: Purpose: To enter unique ISBN of book to be ordered Attributes: EDI-Prefix formally identifies type of message. EDI-Suffix identifies data to immediately follow contents. Datatype identifies format that contents must conform to. Size indicates width of box to be used to capture input. Title indicates text to precede box. --> <!ELEMENT ISBN (#PCDATA) > <!ATTLIST ISBN EDI-Prefix CDATA #FIXED "PIA+5+" EDI-Suffix CDATA #FIXED ":IB" Datatype %EDItype; #FIXED "N12" Size NUMBER #FIXED "12" Title CDATA "ISBN:" > <!--Author and Title element: Purpose: Optional statement of author and title details to confirm correct ISBN has been entered. Attributes: EDI-Prefix formally identifies type of message. Datatype identifies format that contents must conform to. Size indicates width of box to be used to capture input. Title indicates text to precede box. --> <!ELEMENT Author-Title (#PCDATA) > <!ATTLIST Author-Title EDI-Prefix CDATA #FIXED "IMD+F+BST+:::" Datatype %EDItype; #FIXED "C60" Size NUMBER #FIXED "40" Title CDATA "Author/Title:" > <!--Quantity element: Purpose: To identify the number of copies required. Attributes: EDI-Prefix formally identifies type of message. Datatype identifies format that contents must conform to. Size indicates width of box to be used to capture input. Title indicates text to precede box. --> <!ELEMENT Quantity (#PCDATA) > <!ATTLIST Quantity EDI-Prefix CDATA #FIXED "PQTY+21:" Datatype %EDItype; #FIXED "N2" Size NUMBER #FIXED "2" Title CDATA "Quantity:" > <!--Declarations for message control support elements--> <!--Electronic Address element: Purpose: To capture electronic address to which messages from the supplier to the buyer can be sent. --> <!ENTITY % ISOlat1 SYSTEM "A:\ISOlat1.ent" > <!ENTITY % ISOnum SYSTEM "a:\ISOnum.ent" > %ISOlat1; %ISOnum; ]>

Figure A.3: XML Document Type Definition for lite-EDI Book Order

The XSL style sheet used to create the displayed version of the form shown in Figure A.1 took the form shown in Figure A.4: <xsl> <define-script> <![CDATA[ function ISO8601DateCheck(date) { year=date.substring(0,4); /* Microsoft have a bug in substring that means that end is not 0-based, but start is! */ month=date.substring(4,6); month--; /* Microsoft have a bug in their toUTCString convertor of month names! */ day=date.substring(6,8); MessageDate=new Date(year, month, day); return(MessageDate.toUTCString().substring(0,16)); /* Microsoft do not support toGMTString, and to LocaleString does not pick up the default date format set for Windows 95 regional settings. */ } ]]> </define-script> <rule> <root/> <HTML> <TITLE>EDItEUR Book Order </TITLE> <BODY> <FORM METHOD="POST" ACTION="=getAttribute('Send-to')"> <section ALIGN="CENTER"> <select-elements> <target-element type="Title"/> </select-elements> </section> <TABLE BORDER="" cellpadding="4" cellspacing="0" bordercolor="#FF0000"> <TBODY> <select-elements> <target-element type="Order-No"/> </select-elements> <select-elements> <target-element type="Message-Date"/> </select-elements> <select-elements> <target-element type="Buyer-EAN"/> </select-elements> <select-elements> <target-element type="Order-line"/> </select-elements> </TBODY> </TABLE> <DIV style="font: 10pt Arial"> <BR/> <input type="checkbox" name="partial" value="allowed"/> &nbsp;Tick here if a delayed/partial supply of order is acceptable <BR/> <input type="checkbox" name="confirmation" value="requested"/> &nbsp;Tick here if Confirmation of Acceptance of Order is to be returned by e-mail <BR/> <input type="checkbox" name="DeliveryNote" value="required"/> &nbsp;Tick here if e-mail Delivery Note is required to confirm details of delivery <BR/> <BR/> E-mail address: <input type="text" name="e-address" size="30"/> <BR/> <BR/> Please respond in: <select name="response-language"> <option value="EN" selected="selected">English </option> <option value="FR">Fran&ccedil;ais </option> <option value="DE">Deutsch </option> <option value="ES">Espagnol </option> <option value="IT">Italiano </option> </select> <BR/> <BR/> <input type="submit" value="Press here to send completed form to supplier"/> </DIV> </FORM> </BODY> </HTML> </rule> <rule> <target-element type="Order-No"/> <TR> <TD style="font: 12pt Times">Book Order No: </TD> <TD> <INPUT NAME="Order-No" VALUE="=this.text"/> </TD> <TD>Your reference number for order </TD> </TR> </rule> <rule> <target-element type="Message-Date"/> <TR> <TD style="font: 12pt Times">Message Date: </TD> <TD> <INPUT NAME="DATE" VALUE="=this.text" SIZE="8"/> ( <eval>ISO8601DateCheck(this.text) </eval>) </TD> <TD>Date in CCYYMMDD format </TD> </TR> </rule> <rule> <target-element type="Buyer-EAN"/> <TR> <TD style="font: 12pt Times">Buyer EAN: </TD> <TD> <INPUT NAME="Buyer" VALUE="=this.text" SIZE="13"/> </TD> <TD>Your unique identification number </TD> </TR> <TR> <TD style="font: 12pt Times">Supplier EAN: </TD> <TD style="font: 10pt Arial"> <eval>ancestor("Book-Order", this).getAttribute("Supplier") </eval> </TD> <TD ALIGN="center"> <strong>Book Supplies Incorporated </strong> </TD> </TR> </rule> <rule> <element type="Order-line"> <target-element type="ISBN"/> </element> <TR> <TD style="font: 12pt Times">ISBN: </TD> <TD> <INPUT NAME="='ISBN-' + ancestor('Order-line', this).getAttribute('Reference-No')" VALUE="=this.text" SIZE="10"/> </TD> <TD ALIGN="CENTER" rowspan="3"> Order line reference number: <BR/> <SPAN style="font: 10pt Arial;"> <eval> String(Number(ancestor("Order-line",this).getAttribute("Reference-No"))) </eval> </SPAN> </TD> </TR> </rule> <rule> <element type="Order-line"> <target-element type="Author-Title"/> </element> <TR> <TD style="font: 12pt Times">Author/Title: </TD> <TD> <INPUT NAME="='Title-' + ancestor('Order-line', this).getAttribute('Reference-No')" VALUE="=this.text" size="35"/> </TD> </TR> </rule> <rule> <element type="Order-line"> <target-element type="Quantity"/> </element> <TR> <TD style="font: 12pt Times">Quantity: </TD> <TD> <INPUT NAME="='Quantity-' + ancestor('Order-line', this).getAttribute('Reference-No')" VALUE="=this.text" SIZE="4"/> </TD> </TR> </rule> </xsl>

Figure A.4: XSL Processing Rules for Example lite-EDI Book Order

The style sheet is itself coded in XML, conforming to an unidentified meta-DTD specified by the XSL protocol. The first element within this document shows how developers can define functions using the ECMAScript language embedded within XSL. This example converts ISO 8601 format dates to a form that is easier for users to check. This is a simple example of the powerful client-side functionality that can be added to XSL style-sheets.

Note: The comments in the initial function indicate some problems encountered with using the beta release of the MSXSL software.

The remainder of the style sheet consists of a set of <rule> elements that identify a sequence of actions associated with target elements. The actions create HTML flow objects that Internet Explorer 4.0 displays.

Note: It should be noted that these HTML elements have to conform to the XML syntax. This is most evident in the case of the empty line break elements, which are entered as <BR/>

Other significant features that should be noted from this example include: The use of the contents of an attribute of the Book-Order element as the contents of the Supplier EAN row of the table. The call to the ISO8601DateCheck function associated with the rules for displaying the Message-Date element. The use of an attribute associated with the Order-line element to assign information to a set of fields in the displayed form.

Users of Version 4.0 of Microsoft's Internet Exlplorer web browser will find a demonstration of the application of the above simple examples at http://www.xmledi.net/edi-test.htm