Re: [ebxml-dev] Simple Questions

[Todd Boyle <tboyle@rosehill.net>]

Cool!  We should talk!   I need what you're doing.  What you are doing
is what I need.  As long as the service is not a lock in.

Are you aware of the OMG's GL spec, and the recent ARAP submission
done by Netaccount?  I would appreciate your views on those.   The
link to the project is below.

The goals of the project go beyond sending/receiving, to include a
fundamental reconcilation capability.

Finally-- are you interested in working on core components directly,
with me?  I have submitted already, someGL components
http://www.arapxml.net/GLcoreComponentsV090.htm   These are
in an Access database.  I have scripts that produce XML schemas
from the core components.

You may be aware that the CCTs (Core Component Types) are composed
of lowest-level Content models which can all be loaded into the same
table with BCC, ACC, BBIEs and ABIEs.  They are all the same stuff,
with a few particular differences in how the rows would be handled.

You may be aware that an aggregate CC can use other Aggregates,
thus, an entire business document can be assembled from CC.  In
other words you can put business documents as well as CCs in
the registry,

Thus, with the database (Catalog) of Core Components just as it
is today, or as it is changed tomorrow, all elements and their
composition can be stored in an array in memory.  With RAM at
$100/Gbyte who needs an RDBMS for this.  This could be done
in C or COM or Java or VB its so easy.

Here is the latest copy of this junk I'm working on-- python script
reads the CCs into a python list, and grooms it a bit, and then
spews out an XML schema.. it does not handle children.  That is
on the way, but clearly it is not difficult at all, to handle 3 or 4 levels
of detail children.  e.g. a document might be called Mydoc. details
which contains a bunch of elements, of which for example one
might be Something. Details.  This might have Party. Details,
which contains Person. Details.  Which finally has only BCCs.
Then you could subsititute the content model for each BCC and
skip the "Type" such as "Text. Type" entirely,

I'm not pretending this is of much practical use unless it is
mapped with your internal application.  What I suggest is you
change the data elements in your internal application and
use the global data dictionary natively.  Then you're doing
e-business with lower costs.

TOdd
Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
tboyle@rosehill.net  425-827-3107  website www.gldialtone.com
employer www.netaccount.com project www.arapxml.net
"... most of us have a natural tendency and an incredible talent for
processing new facts in such a way that our prior conclusions remain 
intact." -Horngren

At 01:39 PM 11/26/01, Peter Harrison wrote:
>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>

ToddsCoreSchemaGenerator.zip