Re: [ebxml-dev] Simple Questions

[Martin W Sachs <mwsachs@us.ibm.com>]

Peter,

You should look into the ebXML Core Components work. That project builds
business documents from reusable components.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Peter Harrison <peterha@nothingbutnet.co.nz> on 11/27/2001 05:39:29 AM

To:    ebxml-dev@lists.ebxml.org
cc:
Subject:    [ebxml-dev] Simple Questions



Greeting everyone,

I have been lurking around for some time as I have been very interested in
the ebXML project.  I am a developer working on a Open Source system to
transfer business documents between accounting systems.

May of the components for my  system are already open source, such as the
encryption, SMTP, LDAP, and XML Parsers.

I have put together a system which allows companies to send Invoices and
Orders between each other in a 'standard' XML format.  Since the library is
Open Source any accounting system company can implement it with ease.

To be clear about this : I have created a system for the 95% of companies
in
my country who currently use paper and snail mail to deliver invoices and
orders.  Such a system needs to be *very simple*.  However, I my system
does
have a concept which I havn't seen to date - inheritable schemas, so more
complex invoices can be created on top of the simple ones.

The only cetral servers in the system are the LDAP Key Servers used to
propogate public keys or certificates for the encryption and signing
process.

I have been wanting to make this system 'ebXML compliant', however I am
having real trouble understanding how ebXML fits into what I am doing.

My design critierion were:

1. Simple for users.  Sending an invoice to another company with the same
system should be almost as easy as sending an email - if not easier.  Most
businesses don't have the time or resources to spend on wrking out how do
get something done.

2. Simple Infrastruture.  My approach has been a minimalist design.  I do
not try to solve everyones problem in one hit.  I mostly use existing
proven
technology.

3. Standard.  Where possible I will keep to the industry standards.

The real problem for me has been #3.  For example, PGP was my preference
for
encryption and signing, however the number of decisions a user has to make,
and the difficulty in automating the key distribution meant that I had to
implement a similar system to PGP, but which took care of the ease of use
problems of PGP.

My current problem is with ebXML - in that I would like to be 'standard',
but to do so means breaking the simplicity for the users, and the
simplicity
of the architecture.  I am somewhat dissapointed that there is not a
standard minimal  invoice or order which all ebXML systems would be able to
understand, as there is with my approach.

Please understand I am not just 'ebXML bashing' here.  I *want* to support
ebXML in my project if at all possible, but need to resolve these issues.

Regards,

Peter Harrison


----------------------------------------------------------------
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>