RE: Proposed BP PT comments on Requirements

["Todd Boyle" <tboyle@rosehill.net>]

> Paul Levine wrote:
> >I have taken the opportunity to propose a few other
> >revisions that specifically include within the ebXML scope app-to-app
> >applications of XML within an enterprise.  This is very important for large
> >enterprises that have networks of operations support systems that have to
> >interoperate.

Bob Haugen said
 
> Why duplicate what the OAG is doing in this space?
> Is there anything wrong with their efforts?

There isn't anything major wrong with OAG afaics.  But it's
U.S. ASCII isn't it?  I seem to recall one or two complaints
that OAG wasn't optimal for somebody outside the U.S.?  

OAG also has some jarring differences from common business practice 
in SMEs, for example most of the transactions lack an Edit or Delete
message!  90% of small business software enables editing of
posted transactions.  And OAGIS requires, *requires*, a separate
date on every line of a journal entry.  How bizarre.

OAG is big.  There is a common vocabulary called Fields and
Segments, plus, 122 separate transaction doctypes with more
declarations, plus external refernces to the common vocabulary.

Word counts, just in the OAG Fields and Segments DTDs, are 
360 occurrences of ELEMENT, 189 ENTITY, 22 ATTLIST, etc.  Then
there are about 1000 words of OAG vocabulary in it.  That's a 
total of 30K of DTD.  Then, there are very approximately 150K of 
vocabulary in the 122 separate DTDs for 122 transaction types. 
This 150K includes, of course many words which are external 
references to the common vocabulary in the Fields and Segments
DTDs.  But it still includes a huge additional vocabulary. )

Any vocabulary that big is going to reveal something of its authors'
work processes.  These are elements and attributes that 40 U.S. companies
have fought with each other to get into the DTDs!  Naturally there is some
bias to large companies, to products more than services, and 
manufacturing slightly more than distribution.  These things are not
a problem with a vocabulary this big:  you will *never* find anything
that you can't express in OAG.  And when you do, they provide 
this for you, in most DTDs:   <!ELEMENT USERAREA     ANY>

It's dawning on me why these big companies are so quiet about these
schema: they are too good.  They provide a complete roadmap for newcomers
to build terribly good systems.    This is the expert's dilemma:
once you describe your whole problem domain in XML, you're doomed.

> What do you think this will do to the scope of ebXML?
> Won't it require expanding to include everything in the
> OAG standards and then some?

ebXML has a not-very-subtle objective of replacing all emerging
XML standards as well as EDI.  For example, requirments doc.,
section 1.5 "Provide a migration path from accredited EDI and
developing XML business standards"   Note that word "FROM". and
"DEVELOPING".  

I sometimes wonder whether the ebXML workgroup has an adequate
understanding and appreciation of the nature of some existing XML,
and their accomplishments.  For example, requirements doc., 1.10.4.1
refers to "... various competing XML groups, such as RosettaNet,
CommerceOne, BizTalk, XML.ORG. "  These standards are not competing,
they're hardly even in the same dimensions.  Successful XML will
anyways converge around the problem domain in ever tightening 
circles.  Successful XML is an act of perception, not creation.

> Can you explain more about why you are proposing it?
> And maybe more of the scope of your intention?
> (For example, if all you mean is party-to-party dealings within 
> an enterprise, where "parties" are different business units, and 
> the same ebXML B2B standards can be used, then my objections
> do not hold.  But if you mean any and all internal apps, and
> all their integration requirements, I suspect it's a big expansion.)
> Respectfully,
> Bob Haugen

Bottom line:  I strongly support the expansion of scope of ebXML
to include "enterprise integration" as exemplified by OAG Integration
Specification.  This will be highly beneficial to SMEs.  OAGIS is
good and it should be embraced and extended.

Here is why SMEs need "enterprise integration":

The existence of ebXML for conducting B2B commerce will be of little
use to the tens of millions of SMEs and consumers who will never
afford the firewalls, controls, training, maintenance, etc. to use
it.  Instead, they will use multiple DotComs and ASPs on the internet
to conduct business-- web storefronts, billing inboxes, purchasing
portals, dashboards of all kinds.  Payroll services, time/billing
websites.  etc.  

Obviously there will a geometric increase in the connections between
these service providers, in order to share customer and item lists
owned by the same subscriber.

Service providers will also "subcontract" the execution of purchases,
sales, queries and other transactions to other DotComs and infrastruc.
providers.   Obviously, there will also be a single general ledger 
someplace, for every consumer and business, to which every DotCom
must be able to dump its debits and credits.

The exchange of transactions between my own ASPs and BSPs, and my
local site, is "enterprise integration".   None of the B2B XML
vocabularies is designed for this purpose and it is GREAT news that
ebXML will address the need.

Now, how about auto-reconciliation.  The principle is simple: 
A copy of every transaction between every two (or more) parties
should be stored in a shared repository where that transaction
is visible to those two parties alone.  

The existence of this share transaction repository will save millions 
of man years by enabling systems that identify and resolve all differences
in accounts payable/receivable, books and bank, and physical/logistical 
systems and their financial transaction counterparts.

You're building a registry and repository.  Just provide a blueprint
for another 5 or 10 fields for a shared copy of the transactions,
and the specs for the security and timestamping.

Todd Boyle CPA   tboyle@rosehill.net  www.gldialtone.com