RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ... RATHOLE!

[Rachel Foerster <rachelf@ix.netcom.com>]

Mike,

Continuing to slide down your rat hole....is the concept of "on a chip" what
we used to call firmware? Just asking....

Rachel

-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Tuesday, April 23, 2002 9:51 AM
To: David Lyon
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
... RAT HOLE!


RAT HOLE RAT HOLE RAT HOLE!!!

I must be crazy to keep this going - I know I have better things to do.
 See comment in-line.

David Lyon wrote <snipped>:

>Mike,
>
>>Neither says anything about an *embedded* ("on a chip") web server like
>>Apache.
>>
>
>I'm afraid you are wrong.
>
>The Rabbit chip comes with an excellent development kit which features a
>full implementation of TCP/IP. You can check the link out yourself at:
>
>http://www.rabbitsemiconductor.com/products/rcm2200/rcm22_devkit.html
>
>To quote from their documentation:
>
>"Full TCP/IP source code is provided in addition to the Dynamic C software
>on CDROM. ICMP, HTTP (includes facilities for SSI, CGI routines, cookies,
>and basic authentication), SMTP, FTP and TFTP (client and server)
>capabilities are provided"
>
My point exactly.  What's your background David?  Is it business or is
it technical?  If it were the latter, I think you would immediately know
the difference between TCP/IP source code and software on CD-ROM vs.
functionality that is physically burned onto a chip.

All of the software mentioned here runs *on* the chip.  It is not hard
coded "into" the chip.  Do you see the difference?

Assuming that the light bulb has gone off, I think you'll understand my
point about ebXML "on a chip" being a fantasy...

Then again, maybe we just have a different understanding about what "on
a chip" means.

Now, I really do have better things to do.

Cheers,

>
>
>Anyway, maybe an ebXML implementation is a few months off. Who knows. I
know
>that there are quite a few SMEs around the world that would love ebXML on a
>platform like this. So so simple...
>
>Best Regards
>
>David Lyon
>Product Manager
>Global TradeDesk
>
>----- Original Message -----
>From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
>To: "David Lyon" <david.lyon@globaltradedesk.com>
>Cc: <ebxml-dev@lists.ebxml.org>
>Sent: Wednesday, April 24, 2002 12:00 AM
>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...
>RAT HOLE!
>
>
>>RAT HOLE ALERT - Here I go diving down...
>>
>>As I said, David, get real.  The first URL you pointed to says:
>>
>>"This new design takes integration to a new level and saves significant
>>space, cost, weight, and assembly time for designers of embedded
>>systems. PROMETHEUS is an ultra-integrated, ultra-rugged,
>>ultra-efficient design ready for your industrial and commercial
>>application."
>>
>>The second one has a similar write up.
>>
>>Neither says anything about an *embedded* ("on a chip") web server like
>>Apache.
>>
>>
>>David Lyon wrote:
>>
>>>Hi Mike,
>>>
>>>So you're trying to tell me that ebXML could never run on the following
>>>hardware:
>>>
>>>http://www.diamondsystems.com/products/prometheus
>>>
>>>or
>>>
>>>http://www.rabbitsemiconductor.com/products/rcm2200/index.html
>>>
>>>Is there some sort of incompatability ? or something that I don't know
>>>about.
>>>
>>>These devices already run web servers quite fine so I'm interested to
>>>
>know
>
>>>why ebXML couldn't be tacked on them as well.
>>>
>>>David
>>>
>>>----- Original Message -----
>>>From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
>>>To: <ebxml-dev@lists.ebxml.org>
>>>Sent: Tuesday, April 23, 2002 11:40 PM
>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...
>>>
>>>
>>>>David,
>>>>
>>>>While we agree about SME requirements, I think your remedy is a bit on
>>>>the edge of fantasy.  ebXML on a chip?   This reminds me of when people
>>>>were afraid that Microsoft was going to build EDI into Windoze.   I can
>>>>see an XML parser on a chip a lot sooner than ebXML, and I don't expect
>>>>to see a W3C schema validating parser on a chip any time soon.   We
>>>>don't even have fully compliant parsers in software yet!
>>>>
>>>>Get real ;^)
>>>>
>>>>Mike
>>>>
>>>>David Lyon wrote:
>>>>
>>>>>Mike,
>>>>>
>>>>>You're absolutely right.
>>>>>
>>>>>>The main problem is not necessarily with the SME, but with
>>>>>>the tools that are available to them.  Most would accommodate a big
>>>>>>customer's request to do business electronically if it was cost
>>>>>>effective for them to do so.
>>>>>>
>>>>>That's why I say that somebody has to go to Asia and produce ebXML on a
>>>>>chip.
>>>>>
>>>>>SMEs will be able to then afford the product. And you will be able to
>>>>>
>get
>
>>>an
>>>
>>>>>ROI providing that you can make it work.
>>>>>
>>>>>David Lyon
>>>>>Product Manager
>>>>>www.globaltradedesk.com
>>>>>
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
>>>>>To: "Christopher Harvey" <ckharvey@zaratechnology.com.sg>
>>>>>Cc: "'Todd Boyle'" <tboyle@rosehill.net>; <rachelf@ix.netcom.com>;
>>>>><ebxml-dev@lists.ebxml.org>
>>>>>Sent: Tuesday, April 23, 2002 5:15 AM
>>>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
>>>>>
>...
>
>>>>>
>>>>>>Excuse me, but I can't help but violently disagree with most of this
>>>>>>sentiment!  The main problem is not necessarily with the SME, but with
>>>>>>the tools that are available to them.  Most would accommodate a big
>>>>>>customer's request to do business electronically if it was cost
>>>>>>effective for them to do so.  In the current way of doing things (and
>>>>>>I'm afraid how ebXML may turn out the same way) it costs them more to
>>>>>>
>do
>
>>>>>>business electronically than by other means.  And you blame *them* for
>>>>>>that?  That's exactly how the big guys work.  If they can't show an
>>>>>>
>ROI
>
>>>>>>on something, they won't do it.
>>>>>>
>>>>>>Your thinking reflects a big stick approach which I am increasingly
>>>>>>seeing, with large buyers imposing financial penalties of all sorts
>>>>>>
>upon
>
>>>>>>their suppliers in force a shift of costs from the customer to the
>>>>>>supplier.  Does this produce efficiencies?  In some cases yet, but as
>>>>>>often as not it forces the supplier to raise their prices so that they
>>>>>>can recover costs and still make a profit.  This is *not* a very good
>>>>>>
>>>>>model.
>>>>>
>>>>>>We need better solutions, not bigger sticks...
>>>>>>
>>>>>>Christopher Harvey wrote:
>>>>>>
>>>>>>>Rachel,
>>>>>>>
>>>>>>>>What still amazes me is the assumption (apparently) on the part of
>>>>>>>>
>the
>
>>>>>>>large
>>>>>>>
>>>>>>>>enterprise is that if they get their needs meet the small guys will
>>>>>>>>
>>>>>stand
>>>>>
>>>>>>>>up, salute and march on.
>>>>>>>>
>>>>>>>Very true but... I am increasingly of the opinion that unless we use
>>>>>>>
>>>the
>>>
>>>>>>>power of the big guys down onto the SMEs, the latter will not bother
>>>>>>>
>to
>
>>>>>do
>>>>>
>>>>>>>anything.
>>>>>>>
>>>>>>>SMEs do not have much of a collective voice except the scream that
>>>>>>>
>will
>
>>>>>come
>>>>>
>>>>>>>when they big guys hit them were it hurts. So, can we blame the big
>>>>>>>
>>>guys
>>>
>>>>>for
>>>>>
>>>>>>>"taking charge"?
>>>>>>>
>>>>>>>As you may gather, my patience with (some... most) SMEs is wearing
>>>>>>>
>>>thin.
>>>
>>>>>The
>>>>>
>>>>>>>average SME will ignore change until it is forced otherwise (at least
>>>>>>>
>>>in
>>>
>>>>>>>this part of the world). We are slowly getting more and more of the
>>>>>>>
>big
>
>>>>>>>corporations telling our SMEs: "Do it electronically, or lose the
>>>>>>>
>>>>>business".
>>>>>
>>>>>>>Good, about bl**dy time.
>>>>>>>
>>>>>>>The SMEs have only themselves to blame. I am new to ebXML but my 0.02
>>>>>>>
>>>>>cents
>>>>>
>>>>>>>worth is to ask all involved to understand the needs of the SMEs but
>>>>>>>
>to
>
>>>>>use
>>>>>
>>>>>>>the big guys to force change.
>>>>>>>
>>>>>>>Regards
>>>>>>>Chris Harvey
>>>>>>>Zara Technology Pte Ltd
>>>>>>>Singapore
>>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>From: "Rachel Foerster" <rachelf@ix.netcom.com>
>>>>>>>To: "'Christopher Harvey'" <ckharvey@zaratechnology.com.sg>; "'Todd
>>>>>>>
>>>>>Boyle'"
>>>>>
>>>>>>><tboyle@rosehill.net>
>>>>>>>Cc: <ebxml-dev@lists.ebxml.org>
>>>>>>>Sent: 23 April 2002 01:17
>>>>>>>Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
>>>>>>>
>>>...
>>>
>>>>>>>>Chris,
>>>>>>>>
>>>>>>>>Your comments are on the mark! I've personally been a bit dismayed
>>>>>>>>
>>>over
>>>
>>>>>>>the
>>>>>>>
>>>>>>>>life history of the ebXML initiative that what once started out to
>>>>>>>>
>>>have
>>>
>>>>>a
>>>>>
>>>>>>>>focus on "inclusion" of the SME and their needs has instead, at
>>>>>>>>
>least
>
>>>in
>>>
>>>>>>>my
>>>>>>>
>>>>>>>>viewpoint, clearly moved over into the domain of the large
>>>>>>>>
>enterprise
>
>>>>>and
>>>>>
>>>>>>>>what they need/want.
>>>>>>>>
>>>>>>>>What still amazes me is the assumption (apparently) on the part of
>>>>>>>>
>the
>
>>>>>>>large
>>>>>>>
>>>>>>>>enterprise is that if they get their needs meet the small guys will
>>>>>>>>
>>>>>stand
>>>>>
>>>>>>>>up, salute and march on. If the SME's needs are not truly addressed
>>>>>>>>
>>>>>here,
>>>>>
>>>>>>>as
>>>>>>>
>>>>>>>>I said during one of my ebXML Marketing Work Group updates to the
>>>>>>>>
>>>ebXML
>>>
>>>>>>>>plenary, my personal opinion is that the ebXML effort will have
>>>>>>>>
>>>failed.
>>>
>>>>>>>>Rachel
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Christopher Harvey [mailto:ckharvey@zaratechnology.com.sg]
>>>>>>>>Sent: Sunday, April 21, 2002 9:09 PM
>>>>>>>>To: Todd Boyle
>>>>>>>>Cc: ebxml-dev@lists.ebxml.org
>>>>>>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core
>>>>>>>>
>Components
>
>>>>>>>>...
>>>>>>>>
>>>>>>>>
>>>>>>>>Todd,
>>>>>>>>
>>>>>>>>Extremely well put. It's somehow comforting to know that SMEs in the
>>>>>>>>
>>>US
>>>
>>>>>>>have
>>>>>>>
>>>>>>>>the same 'mentality' as SMEs here in Asia.
>>>>>>>>
>>>>>>>>The big gap to be bridged is in getting SMEs to understand that
>>>>>>>>
>there
>
>>>is
>>>
>>>>>a
>>>>>
>>>>>>>>direct financial benefit to be had; opposing that is their belief
>>>>>>>>
>that
>
>>>>>>>their
>>>>>>>
>>>>>>>>data must remain 'secret' (as it had for generations - a necessity
>>>>>>>>
>>>when
>>>
>>>>>>>more
>>>>>>>
>>>>>>>>than one set of books have been historically kept).
>>>>>>>>
>>>>>>>>Rachel is absolutely correct when she says: It's a business
>>>>>>>>
>imperative
>
>>>>>and
>>>>>
>>>>>>>>necessary now and into the future to be able to exchange unambiguous
>>>>>>>>
>>>>>data.
>>>>>
>>>>>>>>As a tech company, we know that. Our government knows that. But
>>>>>>>>
>>>getting
>>>
>>>>>>>SMEs
>>>>>>>
>>>>>>>>to understand that is a whole different uphill struggle.
>>>>>>>>
>>>>>>>>ebXML is an excellent initiative but... the real SMEs, the
>>>>>>>>
>mass-market
>
>>>>>>>small
>>>>>>>
>>>>>>>>ones, with 50 or usually less, employees - which make up the vast
>>>>>>>>
>>>>>majority
>>>>>
>>>>>>>>of companies - have a mindset that you would not believe unless you
>>>>>>>>
>>>have
>>>
>>>>>>>>been exposed to it. For the success of ebXML, and e-commerce in
>>>>>>>>
>>>general,
>>>
>>>>>>>it
>>>>>>>
>>>>>>>>is imperative that all involved with these important initiatives
>>>>>>>>
>have
>
>>>a
>>>
>>>>>>>good
>>>>>>>
>>>>>>>>grasp of the SME mindset.
>>>>>>>>
>>>>>>>>I hope this is not drifting off topic but it is vital that XML
>>>>>>>>
>>>potential
>>>
>>>>>>>>does not become solely the domain of the big players...
>>>>>>>>
>>>>>>>>Regards
>>>>>>>>Chris Harvey
>>>>>>>>Zara Technology Pte Ltd
>>>>>>>>Singapore
>>>>>>>>
>>>>>>>>
>>>>>>>>----- Original Message -----
>>>>>>>>From: "Todd Boyle" <tboyle@rosehill.net>
>>>>>>>>To: <rachelf@ix.netcom.com>
>>>>>>>>Cc: <ebxml-dev@lists.ebxml.org>
>>>>>>>>Sent: 22 April 2002 07:56
>>>>>>>>Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core
>>>>>>>>
>Components
>
>>>>>...
>>>>>
>>>>>>>>>At 09:36 AM 4/21/02, Rachel Foerster wrote:
>>>>>>>>>
>>>>>>>>>>It's a business imperative and necessary now and into the future
>>>>>>>>>>to be able to exchange unambiguous data. And personally I believe
>>>>>>>>>>
>>>the
>>>
>>>>>>>>>>future will be **not** the shipping off to a business partner data
>>>>>>>>>>
>>>or
>>>
>>>>>>>>>>documents, etc. but providing real time controlled access to the
>>>>>>>>>>
>>>>>>>>necessary
>>>>>>>>
>>>>>>>>>>information transparently between enterprises so that
>>>>>>>>>>
>>>cross-enterprise
>>>
>>>>>>>>>>business processes can execute to the desired outcome.
>>>>>>>>>>
>>>>>>>>>As more and more small businesses have always-on connections
>>>>>>>>>to the internet, sooner or later it will dawn on them to expose at
>>>>>>>>>least some limited views or query interfaces to their customers
>>>>>>>>>and suppliers.
>>>>>>>>>
>>>>>>>>>Small businesses often have only one person performing all roles
>>>>>>>>>that interface a particular customer or supplier, and accordingly
>>>>>>>>>have no need for business process management. The cost of updating
>>>>>>>>>all the statuses and stages of a BP exceed their benefit.  Cell
>>>>>>>>>
>>>phones,
>>>
>>>>>>>>>headsets, and the collapse of long distance have made it even
>>>>>>>>>
>cheaper
>
>>>>>>>>>to handle exceptions.
>>>>>>>>>
>>>>>>>>>I don't wish to diminish the usefulness of ebXML BP in any way, for
>>>>>>>>>Enterprise or other value chains where they are appropriate!  But
>>>>>>>>>I think the exchange of documents remains the best potential
>>>>>>>>>way to get ebXML in the door of SMEs.  And, once they gain some
>>>>>>>>>familiarity with it, they will be much closer to supply chain
>>>>>>>>>
>>>>>>>integration
>>>>>>>
>>>>>>>>>or other BP scenarios.  Here is one fictitious dialog for
>>>>>>>>>your entertainment
>>>>>>>>>
>>>>>>>>>Todd Boyle CPA
>>>>>>>>>AR/AP everywhere  www.arapxml.net
>>>>>>>>>
>>>>>>>>>Let's take a break, and get beat up by a small busieness owner....
>>>>>>>>>
>>>>>>>>>Q:  "Why should I allow my customer or supplier to see the purchase
>>>>>>>>>and sale data in *my* accounting system?? "
>>>>>>>>>
>>>>>>>>>A: "you already do.  Whenever you send a PO or an invoice. "
>>>>>>>>>
>>>>>>>>>Q:  Yeah but why should I allow them to see their Account
>>>>>>>>>
>Receivable
>
>>>>>>>>>page, or Account Payable, in *my* system?
>>>>>>>>>
>>>>>>>>>A:  You already do, whenever you send them a statement.
>>>>>>>>>
>>>>>>>>>Q.  Yeah, but I never send statements until they have been reviewed
>>>>>>>>>at the end of the month and the bank account is reconciled to find
>>>>>>>>>all the mistakes in our posting payments.
>>>>>>>>>
>>>>>>>>>A.  Ok then why don't you expose a view of the invoices now,
>>>>>>>>>and expose the reviewed statements at the end of the month?
>>>>>>>>>You don't have to change your procedures at all.  Too bad your bank
>>>>>>>>>is so unhelpful http://www.gldialtone.com/transaction04.htm
>>>>>>>>>
>>>>>>>>>Q.  Well why should I do this, what's the payoff for me?
>>>>>>>>>
>>>>>>>>>A.  Some of your customers might pay you sooner.
>>>>>>>>>
>>>>>>>>>Q.  Yeah but all my good customers already pay me on time,
>>>>>>>>>and my bad customers, I don't think they have the intelligence
>>>>>>>>>to use a computer.
>>>>>>>>>
>>>>>>>>>A.  Maybe when they can login and see their account they will
>>>>>>>>>understand it better.  Maybe they are paying their other suppliers
>>>>>>>>>sooner than they are paying you. Why don't you try emailing them
>>>>>>>>>their statements more often.
>>>>>>>>>
>>>>>>>>>Q.  Yeah but what are you trying to sell me?  You're just trying
>>>>>>>>>to capture me into a central server or single-vendor software.
>>>>>>>>>
>>>>>>>>>A.  Sharing views *directly* with trading partners is the exact
>>>>>>>>>opposite of being trapped in a portal model.  Today, you are
>>>>>>>>>trapped in two separate portal models:  first, you are trapped in
>>>>>>>>>your local software with no electronic interface...
>>>>>>>>>
>>>>>>>>>Q.  Yeah but what am I supposed to "Interface" with?  There is
>>>>>>>>>no standard. Nobody else has any "Interface" either.
>>>>>>>>>
>>>>>>>>>A.  Do you vote?
>>>>>>>>>Q.  Yes.
>>>>>>>>>A.  Do you make charitable contributions?
>>>>>>>>>Q.  Yes.
>>>>>>>>>A.  How much did you contribute last year?
>>>>>>>>>Q.  None of your business.
>>>>>>>>>A.  Transaction integration helps the planet and it doesn't
>>>>>>>>>       cost you anything.
>>>>>>>>>
>>>>>>>>>Q.  What do you mean??
>>>>>>>>>
>>>>>>>>>A.  You're cutting down the paper consumption, getting
>>>>>>>>>vehicles off the road, cutting trips to banks and post offices.
>>>>>>>>>You're saving labor. People can do more useful things.
>>>>>>>>>
>>>>>>>>>Q.  Yeah but what do you mean, "Free"?
>>>>>>>>>
>>>>>>>>>A.  Do you already do accounting work, posting all your sales
>>>>>>>>>and purchases?
>>>>>>>>>
>>>>>>>>>Q.  Yes.
>>>>>>>>>
>>>>>>>>>A.  Then exposing the data to the trading partner costs effectively
>>>>>>>>>nothing. You don't have to compose any new documents. In fact,
>>>>>>>>>the trading partner can freeload off your data entry work.  They
>>>>>>>>>simply click "OK" to suck your data into their computer and post
>>>>>>>>>
>it.
>
>>>>>>>>>Q.  Yes.  But where is the software to do this??
>>>>>>>>>
>>>>>>>>>A. There are modules in the open source ebXML projects, and in
>>>>>>>>>the VARs and developer communities of most of the accounting
>>>>>>>>>platforms.
>>>>>>>>>
>>>>>>>>>Q.  Why that's ridiculous.  You're bullsh*itting me.   Integration
>>>>>>>>>always costs megabucks.   I have been burned many times in
>>>>>>>>>the past by computer consultants.
>>>>>>>>>
>>>>>>>>>A.  In the past, the N-squared problem required a separate
>>>>>>>>>software solution for every combination of thousands of software
>>>>>>>>>products, that is, *millions* of adapters to connect with each
>>>>>>>>>
>other.
>
>>>>>>>>>Since ebXML is a common format, each accounting platform only
>>>>>>>>>needs one adapter.
>>>>>>>>>
>>>>>>>>>Q.  Well, I don't believe you.   Anyway, you said I am already
>>>>>>>>>locked into  *two* different portal traps. What's the other one?
>>>>>>>>>
>>>>>>>>>A. You are trapped in the banking system with no other way to
>>>>>>>>>settle ARs or APs except by running payments through banks
>>>>>>>>>for each and every payment.  That wrecks your bookkeeping and
>>>>>>>>>your trading partner's bookkeeping, since banks only process
>>>>>>>>>payment data and block all the transaction data between small
>>>>>>>>>businesses.
>>>>>>>>>
>>>>>>>>>Q.  That's right.  So, what good is AR/AP integration between me
>>>>>>>>>and my trading partner?
>>>>>>>>>
>>>>>>>>>A.  Settlement intermediaries such as accounts receivable factors
>>>>>>>>>can't be cheap today because the data is so confused.  But even
>>>>>>>>>a robot can do settlement if data is good.  And if collateralized.
>>>>>>>>>What you are doing is uncoupling the interest cost and the risk,
>>>>>>>>>which cannot be avoided.  You are making the mechanics of
>>>>>>>>>
>accounting
>
>>>>>>>>>and settlement cheaper.
>>>>>>>>>
>>>>>>>>>Derivatives, promissory notes or digital cash become more
>>>>>>>>>
>practical,
>
>>>>>>>>>when you have high quality data.  Do you think global corporations
>>>>>>>>>all write checks or bank transfers to each other?  at the end of
>>>>>>>>>each month?  Not.
>>>>>>>>>
>>>>>>>>>Q.  OK you're telling me to provide a SOAP interface on my ARs
>>>>>>>>>to my customers, and my APs to my suppliers???
>>>>>>>>>
>>>>>>>>>A.  Yes.
>>>>>>>>>
>>>>>>>>>Q.   Go away.  That's just not the way we do business in podunk.
>>>>>>>>>
>>>>>>>>>A.  Ok tell you what.   Why don't you pass me your ARs and APs
>>>>>>>>>in UBL, in ebXML core components format, every time you do a
>>>>>>>>>purchase or a sale.   You show me how much it's costing you,
>>>>>>>>>screwing around with AR and AP, your banking and bank
>>>>>>>>>reconcilation, and other settlement after the conclusion of a sale.
>>>>>>>>>I will manage the ARs and APs and bank balances for you for 1/2
>>>>>>>>>cost.  I will bounce all the business differences back to you,
>>>>>>>>>
>since
>
>>>>>>>>>you're the only one who can resolve them anyway.
>>>>>>>>>
>>>>>>>>>Q.  Ok.   Deal.
>>>>>>>>>
>>>>>>>>>A.  Ok then why don't you let the computers connect, and do it
>>>>>>>>>for nothing?  You realize, in the long run, I'm going to be
>>>>>>>>>
>charging
>
>>>>>>>>>you money for operating a robot software I got from ebXML
>>>>>>>>>open source?    sheesh...
>>>>>>>>>
>>>>>>>>>Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
>>>>>>>>>International Accounting Services, LLC  www.gldialtone.com
>>>>>>>>>425-827-3107  AR/AP everywhere  www.arapxml.net
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>----------------------------------------------------------------
>>>>>>>>>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>
>>>>>>>>>
>>>>>>>>----------------------------------------------------------------
>>>>>>>>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>
>>>>>>>>
>>>>>>>----------------------------------------------------------------
>>>>>>>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>
>>>>>>>
>>>>>>>
>>>>>>--
>>>>>>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>
>>>>>>
>>>>--
>>>>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>
>>>>
>>>
>>--
>>Michael C. Rawlins, Rawlins EC Consulting
>>www.rawlinsecconsulting.com
>>
>>
>>
>>
>
>

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