RE: VOTE REQUESTED - Suggest vote NO to Section 7 of the TechnicalArchitecture Specification

[David RR Webber <Gnosis_@compuserve.com>]

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.