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: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

On Tuesday 23 April 2002 05:17 am, you wrote:
> 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.

I have been lurking on this list for some time. My hope was that I was
missing something, that if I just learned more about ebXML I would understand
how ebXML will address some vital needs for small business. The above
message, and others previously make me now believe this not to be the case.

According to New Zealand Government Statistics about 95% of all businesses in
NZ have computers. Of those businesses 95% have an Internet connection. And
how many NZ businesses use the Internet for ecommerce? under 5%!

A huge majority of businesses are still stuffing paper invoices into
envelopes and spending 40 cents to physically deliver them - while at the
same time using email to communicate with the very same entities they are
invoicing. The same computers used for email are also used for accounting
systems - all that is missing is a way for accounting systems to send the
invoices in an email.

My original (mis)understanding was that ebXML would provide a standard - a
specification or XML schema for say - and invoice. We could then create a XML
invoice and send it, and know that because its a standard that it would be
supported at the other end if they have complying software.

Lets avoid the issue of transport security right now - because thats trvial -
I've already developed an open source implementation working based on PGP.

My primary concern is that rather than specifying a simple standard like HTML
or POP3 or SMTP which can be easily understood and easily implemented by
software companies there is now a complex, hard to understand solution which
doesn't really even provide any standard, and doesn't address the basic need
to send a invoice in an email.

I mean, if I were to ask you to send me a schema for an invoice so I can send
to someone with ebXML I will find there isn't one - not a universal one -
that I have to negociate with the receiver about their format.

The fact is (at least in NZ) that an invoice will have the same information
on it for 95% of the companies. There is no reason we cannot have a standard
invoice schema for 95% of companies. Then to cater for the remaining
companies - large corporates who have specific needs - we can allow
inheritance, so that they can add stuff to the invoice schema - but not
delete stuff.

That way if a invoice is received from BigCorporate by SME the SME can still
understand most of the body even though it contains additional elements.

It seems to me that a huge amount of work is being done to please corporates
who in the main have existing EDI systems anyway, while very little is being
done to address the much simpler needs of the SME. All they need is a way to
replace their paper transports with electronic transports. Turn paper to

More than a year ago I started a open source project called "Internet
Document Transfer". I have already implemented the transport system, which
allows users to send files to each other encrypted with no messing about to
understand public keys and suchlike (public key crypto is still used, but key
handling is automatic).

I have also developed a system of inheritable schema, although I might have
duplicated the work of the W3C in some respects, and I have developed my own
lightweight parser. Finally I have developed an actual application to send
and receive invoices and orders as a proof of concept. What I am saying is
not that everyone should start using my project - but that we could address
the needs of SME's very quickly because in the main their existing system is
simply paper. Trying to replace heavyweight EDI is much harder.

On to addressing Christopher Harvy's post:
> 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.

Currently SME's have no compelling software. Literally. The accounting system
companies I have talked to each have to maintain large numbers of file
interfaces to deal with importing and exporting data from various other
accounting systems. There is no simple solution to send an invoice like there
is to send a simple text message. Generally there is no transport mechanism
at all.

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

What we don't seem to be addressing is that the needs of the corporates are
very different to the simple needs of the SME's. All this stuff about forming
relationships doesn't relate much to the transactions of an SME which are
mostly adhoc - ie with people they will not have an ongoing relationship

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

Most SME's I have delt with would just love an easy way to transmit invoices
and orders. The problem is that there is no standard for the accounting
companies to decide on. They don't want to pay for ongoing 'translation'
services. Perhaps they are just as frustrated with you if what you are
pushing on them isn't something that fits their business?

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

The needs of corporates nd SME's are different. The corporates will push for
complex expensive solutions that they will use to replace the complex EDI
solutions they have now. SME's just want something to send and receive common
business documents.

Besides which, having a common standard will be good for everyone - even
corporates. Sure they will have to inherit from the standard to build in the
needed functionality, but at least they wouldn't need to worry about whether
joe bob SME has a compliant system.

Finally a comparision:

Imagine a world in which email used an ebXML like system - a world where
there was no SMTP, and every email software company used a different
protocol. In order to make it all work large translation services would
charge users to translate between all the different protocols. The protocols
themselves would be very complex because they would need to cater for all the
functionality required in corporates. Email software is very expensive
because of the complexity of dealing with all the functionality. And only 5%
of people on the Internet would be able to afford it - both in terms of
software and transmission fees.

This is what we are heading for if we drive the standartd according to
corporate needs. However, if we address the needs of the SME - create simple
standards like SMTP it will benefit both SME's and corporates.

View my project at:

By the way, if you are interested in helping me with my open source
implementation please let me know. I am not making any money on the project,
so currently its part time. I need more developers to help move it forward.
The current work is in Delphi and Java, although ports to C and other
languages would be welcome.


Peter Harrison
Nothing But Net Limited

[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