Is XML the eBusiness savior?
31 May 2007 15:21 Filed in: Standards
In 1998 there were various moves towards XML as an EDI replacement. Towards the end of that year UN/EDIFACT users demanded that UNECE (CEFACT) created an XML solution in order to protect is investment and leading role as the standards setter in electronic information exchange. This resulted in the recommendation not to transform EDI messages into XML, but instead to use XML where appropriate in its next generation effort, which led to the creation of ebXML.
I already addressed in my previous postings the results of the ebXML initiative. Because of the CEFACT decision not to create XML/EDI messages as part of ebXML this topic still needs to be addressed. Since the creation of XML there have been many attempts to create XML based eBusiness messages. Some of those formats no longer are in use, other are still emerging. So why create new XML based messages instead of continuing to use EDI based eBusiness messages?
To answer that question we must first identify the benefits XML over EDI. Who better to point out what those benefits may be than Jon Bosak (The Father of XML). Jon has given many presentations using the following two slides to point out XML’s benefits for the use within Electronic Commerce:
I accept Jon’s first statement that “XML promotes a message-oriented view of electronic commerce …”, however, the same is true for EDI since both X12 and UN/EDIFACT cover all his business message examples.
So let’s concentrate on the XML advantages over EDI since they are not only used by Jon but by most XML experts entering the eBusiness area.
Explicit structure
The argument being that XML structures express all required semantic details in a clear and obvious way, leaving no doubt as to the intended meaning.
If one only looks at the transmitted data it is true that depending on the detailed XML tag content that XML messages contain more semantic content than EDI messages. However, how many user care about this as they never look actually at the transmitted data in raw form? Looking at the latest version of CEFACT’s new XML based Cross Industry Invoice Schema shows less detail than the supporting implementation guide of the UN/EDIFACT Invoice. The question is what does the implementer require to setup the eBusiness system to exchange data with its trading partner? For the XML Cross Industry Invoice implementers need to work with 27 additional support schemas to fully understand what data is required and how to map it to/from the in-house application data. Yes, XML tags are human readable but having to plow thru 28 schemas is not an easy task. Thanks to the existence of Industry or Company specific implementation guides a single document is all a EDI implementer needs to deal with.
Bottom line: XML offers some help in debugging during initial implementation and testing of a new message exchange, but ones setup there is no benefit gained using a XML structured message over a EDI structure. Some may claim that EDI structures are more efficient to process than XML based structures. For now I will leave that one alone.
Easier validation
There is no arguing validating a XML document for structural integrity and correctness, of a message instance is easier because of the many free tools/programs available. EDI validation is build into EDI translators that are not free and their cost can be very high. XML developers don’t need to create their own programs to include XML validation whereas EDI developers must create their own programs. But it does not end there for EDI. Currently all good commercial EDI applications also include content checking based on specific application parameters defined in their implementation guides and part of their EDI mapping rules. Most EDI mappers are deploying a graphic user interface with drag and drop that allows for easy entry of those requirements. XML will allow content rules within schemas but would require the changes to be preformed within a text-based editor to modify the standard distributed schemas for their specific implementation.
Bottom line: Standard message validation is much easier for XML implementers, however if content compliance is required utilizing a good commercial EDI application will offer a easier way to do so for EDI users.
Can easily use the Internet
This may have been true before 1999, but with the emergence of AS1/AS2 and ebXML’s Message Service protocols there is no difference in ease to use the Internet for EDI message exchanges over that of XML. It is true that the majority of EDI users are still using a Value Added Network (VAN) service, but not because of the ease of use but the added services that are not available when using the Internet. It should also be noted that most VAN services now use the Internet instead of dial-up or direct-connect.
Bottom line: No longer a valid argument.
Cheaper to implement
There was originally some hope that XML could be used to produce a eBusiness solutions more attractive to small and medium sized businesses (SMEs) that would be less trouble to use. The argument was to use forms-based applications within Web browsers, with options to save the data in document formats.
This is one approach I've never understood, and I've seen a few, Web based applications “targeted to SMEs that require a user to key data into a form to produce a XML (or even EDI) invoice. Why on earth would an SME want to key in data into yet another application just to produce an electronic document? eBusiness solutions for SMEs should integrate with the applications of that SME and be able extract/import the necessary XML/EDI data. Otherwise, we just making life even more difficult for SMEs and giving them yet another reason to hate computers!
One may argue that building a XML based eBusiness system similar to EDI is cheaper to produce because of the use of open-source XML components, such as XML parsers and valuators. The statement of XML being cheaper to implement was born from the fact that in the early days most adaptation of XML in the eBusiness world were “homegrown”. Today most commercial eBusiness applications available process both EDI and XML messages and therefore the cost is the same to the end user.
As to the last argument presented by Jon that XML “can open up electronic commerce to small and medium-size businesses”, I will address the validity in my next post at which time I will also answer the over all question “Is XML the eBusiness savior?”
I already addressed in my previous postings the results of the ebXML initiative. Because of the CEFACT decision not to create XML/EDI messages as part of ebXML this topic still needs to be addressed. Since the creation of XML there have been many attempts to create XML based eBusiness messages. Some of those formats no longer are in use, other are still emerging. So why create new XML based messages instead of continuing to use EDI based eBusiness messages?
To answer that question we must first identify the benefits XML over EDI. Who better to point out what those benefits may be than Jon Bosak (The Father of XML). Jon has given many presentations using the following two slides to point out XML’s benefits for the use within Electronic Commerce:
What XML does for business?
XML promotes a message-oriented view of electronic commerce that isolates business transactions from differences in software, hardware, system architectures, and application programming languages.
Examples of business messages:
- purchase order from a buyer to a seller
- invoice from the seller back to the buyer
- request to make payment through a credit card
- authorization to use credit card
- status reports on success or failure of services
Advantages of XML over EDI:
- Explicit structure
- Easier validation
- Can easily use the Internet
- Cheaper to implement
- Can open up electronic commerce to small and medium size businesses
I accept Jon’s first statement that “XML promotes a message-oriented view of electronic commerce …”, however, the same is true for EDI since both X12 and UN/EDIFACT cover all his business message examples.
So let’s concentrate on the XML advantages over EDI since they are not only used by Jon but by most XML experts entering the eBusiness area.
Explicit structure
The argument being that XML structures express all required semantic details in a clear and obvious way, leaving no doubt as to the intended meaning.
If one only looks at the transmitted data it is true that depending on the detailed XML tag content that XML messages contain more semantic content than EDI messages. However, how many user care about this as they never look actually at the transmitted data in raw form? Looking at the latest version of CEFACT’s new XML based Cross Industry Invoice Schema shows less detail than the supporting implementation guide of the UN/EDIFACT Invoice. The question is what does the implementer require to setup the eBusiness system to exchange data with its trading partner? For the XML Cross Industry Invoice implementers need to work with 27 additional support schemas to fully understand what data is required and how to map it to/from the in-house application data. Yes, XML tags are human readable but having to plow thru 28 schemas is not an easy task. Thanks to the existence of Industry or Company specific implementation guides a single document is all a EDI implementer needs to deal with.
Bottom line: XML offers some help in debugging during initial implementation and testing of a new message exchange, but ones setup there is no benefit gained using a XML structured message over a EDI structure. Some may claim that EDI structures are more efficient to process than XML based structures. For now I will leave that one alone.
Easier validation
There is no arguing validating a XML document for structural integrity and correctness, of a message instance is easier because of the many free tools/programs available. EDI validation is build into EDI translators that are not free and their cost can be very high. XML developers don’t need to create their own programs to include XML validation whereas EDI developers must create their own programs. But it does not end there for EDI. Currently all good commercial EDI applications also include content checking based on specific application parameters defined in their implementation guides and part of their EDI mapping rules. Most EDI mappers are deploying a graphic user interface with drag and drop that allows for easy entry of those requirements. XML will allow content rules within schemas but would require the changes to be preformed within a text-based editor to modify the standard distributed schemas for their specific implementation.
Bottom line: Standard message validation is much easier for XML implementers, however if content compliance is required utilizing a good commercial EDI application will offer a easier way to do so for EDI users.
Can easily use the Internet
This may have been true before 1999, but with the emergence of AS1/AS2 and ebXML’s Message Service protocols there is no difference in ease to use the Internet for EDI message exchanges over that of XML. It is true that the majority of EDI users are still using a Value Added Network (VAN) service, but not because of the ease of use but the added services that are not available when using the Internet. It should also be noted that most VAN services now use the Internet instead of dial-up or direct-connect.
Bottom line: No longer a valid argument.
Cheaper to implement
There was originally some hope that XML could be used to produce a eBusiness solutions more attractive to small and medium sized businesses (SMEs) that would be less trouble to use. The argument was to use forms-based applications within Web browsers, with options to save the data in document formats.
This is one approach I've never understood, and I've seen a few, Web based applications “targeted to SMEs that require a user to key data into a form to produce a XML (or even EDI) invoice. Why on earth would an SME want to key in data into yet another application just to produce an electronic document? eBusiness solutions for SMEs should integrate with the applications of that SME and be able extract/import the necessary XML/EDI data. Otherwise, we just making life even more difficult for SMEs and giving them yet another reason to hate computers!
One may argue that building a XML based eBusiness system similar to EDI is cheaper to produce because of the use of open-source XML components, such as XML parsers and valuators. The statement of XML being cheaper to implement was born from the fact that in the early days most adaptation of XML in the eBusiness world were “homegrown”. Today most commercial eBusiness applications available process both EDI and XML messages and therefore the cost is the same to the end user.
As to the last argument presented by Jon that XML “can open up electronic commerce to small and medium-size businesses”, I will address the validity in my next post at which time I will also answer the over all question “Is XML the eBusiness savior?”
0 Comments
