Identifying Data Sets

Whereas existing EDI definitions are primarily concerned with the way in which a set of fields form a message, the concepts required for XML/EDl 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 XMI/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 ED1 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, 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.

Domain Name Search