Re: [ebxml-dev] ebXML CPA/CPP Estimate

Dale Moberg wrote <snipped>:

> "Instead of configuring a system with
> lots of parameters from a CPP I
> vote for specifying reasonable defauts
> for all those parameters. This is
> much more cost saving on the SMB case."
>
> Gee Berndt, I don't know how we missed this!
> Next time you should come to a meeting and
> explain to everyone what the "reasonable defaults"
> on all transport, acknowledgement, NRR,
> reliable messaging, signals, signatures,
> trust anchors, certificates, digital envelopes,
> transport security should be for all types of
> all business collaborations (from product
> announcements to authorization for fund
> transfer) for all variety of organizations
> (government, educational,
> Fortune1000, SME, midsize, and so on).
> We could use your help! You might also find
> out why this approach never works in practice,
> and why we have _options_. Then you will understand
> why we are trying to make configuration
> of options easier, and to arrive at interoperable
> solutions even when options exist. No wonder
> you agree with Mike.

And that, folks, is the crux of the problem.  While ebXML obviously had to
support multiple constituencies, the only two which were singled out in the
foundation documents were small to medium enterprises and developing
countries.   Every time a design decision was to be made, these two
constituencies should have been given preference.  I see little evidence
that this was the case.  Yes, the CPA/CPP is a useful aid in configuring a
complex messaging system.  The real issue is the complexity of the messaging
system.  I will deal with this and related issues in the final article in my
series.

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com



----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>