Technical Archecture Topic

One of the primary technical advantages that XML offers, over today�s EDI, is modularity.

EDI technology includes a variety of discrete elements: mapping
support, management system, trading partner profiles, message
validation, etc. Each of these message processing elements are custom designed and coded by the various translator vendors. There is little to no option to select the best components from each vendor, in order to construct the optimum solution for the users purpose.

In contrast, in the XML world we have DTDs, XSL, schemas, message syntax, etc., specifying standard interfaces for each aspect of the message processing flows. This approach will result in a broader and technically more robust, range of technology options in the marketplace.

Furthermore, one could predict a set of usage profiles ranging from the low end consumer market with casual interactions, a range of SME�s, large organizations, and ultimately trading community automation. Associated with each of these usage profiles, one could profile technology requirements for each of the aspects of message handling/processing components.

This is a critical deliverable from ebXML, and it seems that work should be occurring in both the requirements and technical architecture project teams.





PDP