XML/EDI
... for traditional (ASC)
X12 and UN/EDIFACT
standards
XML/EDI-R...
for rule-based
XML/EDI-OO
... for object-based
XML/EDI-BSI... for BSI
implementations
......
[Archive copy mirrored from: http://www.geocities.com/WallStreet/Floor/5815/answers.htm]
General Issues
Application Specific Questions
Yes. XML/EDI is based on XML which is a subset of the proven SGML technology, which is already in use at places such as the Library of Congress. EDI has been around for over 25 years and is currently being implemented at thousands of locations.
Yes. XML/EDI Group is currently defining an "EDI application for XML".
XML is working group at the World Wide Web Consortium (W3C). The XML Specification exists in two parts --
EDI relies on the use of standards for the structure and interpretation of electronic business transactions. All trading partners must use a common standard, which reduces errors and ensures accurate transmission of data, regardless of the computer systems involved. ANSI chartered the Accredited Standards Committee (ASC) X12 in 1979 and United Nations has defined rules for EDI under UN/EDIFACT. The Federal Government has endorsed the use of ANSI X12 Standards for EC / EDI with the U.S. Government through Federal Information Processing Standards Publication 161.
We anticipate XML/EDI will change the way document-based transactions are exchange. Today, XML/EDI is so new most companies are unaware of its existence. Because of the support XML and EDI has been given, we believe the companies in these areas will adopt an XML/EDI strategy. Led by Microsoft, XML is supported by Sun, SoftQuad, NCSA, Hewlett-Packard, and now Netscape (as of April 1997), among other companies. EDI is supported by thousands of small and medium companies as well as the Fortune 100 corporations.
XML/EDI is an XML Application, which means any browser which supports XML will be able to interact with XML/EDI documents. Internet Explorer version 4.0 will support a few XML applications (such as CDF). Microsoft will be supporting XML in future versions of Internet Explorer. Netscape in April 1997 pledged to support XML in its future browsers.
No. While XML/EDI has the characteristics of presentation and data structure and will be easily displayed within a browser which supports XML, XML/EDI will allow all document-centric tools to be used to manipulate, store, search, etc. the transactions. XML/EDI combines structured and unstructured data in one entity.
No. As stated above XML/EDI is a standard for formatting documents. How these documents are transmitted to each other or stored is up to the underlying applications. XML/EDI transactions can be FTP, Emailed (SMTP), etc. just as you would any other document. Likewise XML/EDI documents, being at the application layer, can be transmitted via a VAN, Intranet (WAN) or Internet. XML/EDI fits well within the trend of electronic commerce taking place on the "superhighway", and can extend traditional client/server applications within most architectures. Also whatever the security implemented at the transport layer can be enhanced at the application layer.
This is a good question. For years many efforts have been underway to forge the direction of EDI - some building on existing standards, others literally beginning again. XML/EDI is NOT yet another "solution" to solving the EDI integration problem by itself. By creating an 'EDI application for XML', we open the door to allow a new suite of tools and "hooks" available to the applications integrator. These new tools and hooks into the transaction helps facilitate these new methods of electronic data interchange.
To accomodate these various methods of integration, the following nomenclature has been defined:
......
Generically these are called XML/EDI, and when specific attributes are addressed, the suffix is called out. Note: a form of EDI called Lite-EDI was the first released XML/EDI option proposed. You see, XML/EDI is a protocol which allows for many different integration methods.
We believe EDI administration should be reduced through the use of these document-centric tools - but not eliminated. The use of XML as applied to data interchange will bring the people involved with the various documents closer to the transaction process. The work currently under way to better integrate EDI with applications will be needed, and should further the spread of EDI. These methods of "mapping" the tagged data or tools for prompting the originator of the documents are very much like HTML authoring tools are today, but with access to common agreed upon applets and standards.
Tools which allow the user to focus on the content of the document as opposed to its structure and transport. These are WYSIWYG authoring tools, browsers, search engines, message-bases, and Email systems, etc. Currently EDI (at least a far majority, excluding EDI-FAX-EDI systems) map the transactions into and out of a database? Only a few databases allow for full-text search of the criteria required for selecting records pertaining to business requirements. Document-centric tools can complement your RDBMS tools to allow effective search and manipulation of your transactions.
Search engines today are very good at pulling out information from textbases and Web pages. But to pull "fielded" data accurately, some form of tagging system must be used. XML/EDI allows for the structured data to be included with unstructured text in the same document. In many cases, text documents are generated from structured databases, XML/EDI allows for retaining this structure during the publishing of the text document. With the prediction of more and more information to published on the Internet, selective searching and agent technology is said that systems will interact at a higher level than today. XML/EDI will be one piece of the pie to make this a reality.
A scenario could goes as follows... a standard commercial search engine, which has been taught to retrieve XML-based information, to query from an XML database residing on an organizations Intranet or Internet pages, e.g. catalogs on the Internet. In the scenario the user will be able to pose a query as, "Find me a organization who ... and specializes in ...." The query would search for tags associated with those found in the EDI standards, and the Java code assigned to those tags would allow for their processing. Sounds too futuristic, not with XML/EDI combined with other technologies.
As you could have guessed by now, XML/EDI parsers and document generators can easily work with today's EDI templates via pre- and post-processing functions. Today do you write your EDI viewers? Or purchase them? If you purchase them what is the delay from when you want to use the IC to the date the manufacture delivers them? If you do the templating inhouse how many people work on these and for how long? How long did it take to learn the scripting or template tags? With XML/EDI this task is considerably easier and standardized. Easy enough that your templating/mapping task won't have to be delegated to a team of human "mappers" or programmers; but instead will be extensions to "front-end" tools such as word processors, spreadsheets, database and business object viewers.
XML/EDI as a protocol is by definition system independent. Tools will be developed to interact with XML/EDI documents, probably starting with those systems which support major web browers. It is anticipated then, other mechanism will fall into place which will manipulation, transmitting, viewing the transactions on a variety of machines.
XML/EDI will allow for "cell" or "node" application routing, with local integration. This will complement the centralized EDI processing implemented today. Do you ever need to automatically route transactions (at the application layer) based on content of the transaction document - excluding ISA and GS? If so, XML/EDI will assist with this by enhancing the document-centric technology used to "push" information today to filter/sort this to your desktop.
This depends on the transport not XML/EDI. Certainly, if you need your transactions to be relatively interactive, your applications can be as near-realtime as the Web is today by implemeting XML/EDI. If fact, it is predicted that a majority of the transactions will take place on the Internet.
Yes, they certainly can. XML extends HTML, and one can view the variety of pages on the Web to see what is possible. Does your customer's application require/desire the form destination to look like their current paper-based system? With XML/EDI this is possible, using the markup authoring tools in abundance today - no more forcing of "common denominator" templates.