OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

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.


Peter Harrison

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC