Subject: RE: VOTE REQUESTED - Suggest vote NO to Section 7 of the TechnicalArchitecture Specification
Message text written by Rebecca Reed > Furthermore it isn't just a simple transformation problem - the document or documents may need to be combined into (or separated into) the various tables and elements of the data structures that support the various accounting systems - so it isn't just a simple transformation problem but rather an integration problem. Mercator is one product (there may be others) that supports a many-to-many integration and can easily accommodate the integration and transformation requirements of these various accounting systems - but it is a case-by-case scenario for each accounting application that would have to be written for each of these systems. <<<<<<<<<<<<<<< The whole point is to ENABLE this. As one vendor that has figured out how to use Core Components and Registry to do EXACTLY this - right now I'm sure the other vendors will figure it out eventually. The whole problem here is NOT that ebXML does not do this - but that there is too much turf-protecting going on and vendors do not want to open up their backend systems in an open way using Bizcodes and UIDs. For an example of this see http://www.catxml.org - where the use of ebXML style interoperable definitions has been in place for over a year - and right now we're reviewing moving this all to ebXML compliant TRP and SOAP messaging. So why have all the catalogue vendors not rushed to embrace an open standard? That's the real issue here - not the ebXML spec's and scope. There's an old saying 'You can take a horse to water, but you can't make it drink". DW.
Powered by eList eXpress LLC