[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the ebXMLBusinessDocument framework
Todd
I absolutely agree that there is an enormous difference between trying to
implement directly from the EDI published standards and implementing from a
business community guideline.
Arguably the biggest mistake that EDI standardisation ever made was not to
include the definition and harmonisation of implementation material within
its charter from day one. This is a crucial element that ebXML is including
in all its CC and BP work due to the unique combination of real business
expertise contributing to the work. As this work continues on into the
future it is key that syntax implementations are based on what is actually
used and also that all the required semantic definitions are as globally
well defined and harmonised as can possibly be achieved.
This was certainly what we tried to do from the best information available
at the time when constructing the 30 version of the xCBL library.
Sue
Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080
www.commerceone.com
-----Original Message-----
From: Todd Boyle [mailto:tboyle@rosehill.net]
Sent: 31 March 2001 03:24
To: 'ebXML Core'; stuart.campbell@tieglobal.com
Cc: bosak@boethius.eng.sun.com; 'William J. Kammerer'
Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the
ebXMLBusinessDocument framework
Stuart Campbell said March 30, 2001 2:51 PM
> > Personally, I would be thrilled if UN/CEFACT adopted xCBL as
> > the beginning of a new vocabulary.
>
> ***Todd, could you convince me why a new VOCABULARY is necessary.
> EDIFACT+ has this. XML only offers a structure and the Vocabulary
> of xCBL either takes into account all (for some) and for others
> (like me) its a pale and very limited subset combared with the scope
> of EDIFACT
I am not hopeful that I will convince *you* but here is why I am
convinced: the range of metadata that must be supported is excessive.
Since I am an accountant and working on a GL project, I have this
EDIFACT ENTREC message for General Ledger data. Here is a very
brief outline of the GL message, I am leaving out *many* details.
I am only including the segments which have more than 20 or 30
types. (these are metadata names that normally have their own column
in a transaction database--they are not data values)
Beginning of message
1001 doc. name codes 549 possible types of documents.
1131 Code List identifiers 243 possible types of codes.
3055 Agencies controlling lists 266 agencies
1225 Function (add, delete, etc) 60 actions or functions
4343 Response 19
RFF references about the message
1153 reference codes 707 types of codes
NAD name and address
3035 party function (role) 490 roles or relationships
1131/3055 codelist/agency pairs 243 code types; 266 agencies
1153 another set of refrnc codes 707 types of codes
CTA contact information...
3139 contact function codes 95 various job titles/roles
COM communication contact
3155 number types 34 kinds of phone,fax etc. nos.
CCI accounting, legal etc. characteristics
Measuremt details
6313 attribute codes 219 attributes you might track
Product characteristics
1131/3055 codelist/agency pairs 243 code types; 266 agencies
CAV association characteristic values
1131/3055 codelist/agency pairs 243 code types; 266 agencies
DTM DateTimePeriod about this journal
2005 DateTimePeiod functioncodes 697 adjectives that might apply,
2379 DateTime formats 74 formats that may be used.
RJL accounting journal identifcn.
Acctg Journal ID
1131/3055 codelist/agency pairs 243 code types; 266 agencies
Acctg. Entry type details
1131/3055 codelist/agency pairs 243 code types; 266 agencies
Control total information for the file:
6063 quantity type,what's counted 412 quantity types
6411 UOM 1532 units of measure
RFF reference codes
1153 reference codes 707 types of codes
DTM DateTimePeriod of the period
2005/2379 DateTimePeriod pairs 697 adjectives, 74 DateFormats
MOA monetary amounts for some control totals
5025 monetary qualifiers 496 kinds of amounts.
4405 Status description code 94 statuses, debits, credits etc.
WHEW - NOW WE CAN START WITH THE JOURNAL HEADERS AND
TRANSACTION ENTRIES:
TRANSACTION HEADER starts here, I think.
----------------------------------------------
IND Index details
1131/3055 codelist/agency pairs 243 code types; 266 agencies
RFF reference code to the source document
1153 reference codes 707 types of codes
TRANSACTION ENTRIES start here, I think.
----------------------------------------------
CPT Account identification
(the chart of account name/code are freeform strings)
1131/3055 codelist/agency pairs 243 code types; 266 agencies
4437 account types 16 types of accounts
DTM DateTimePeriod of the entry
2005/2379 DateTimePeriod pairs 697 adjectives, 74 DateFormats
PAI payment instructn/settlement method
4439 conditions 72 conditions for payment
4431 guarantees 14 various fiduc. guarantees
4461 means 70 means assoc. with payment
1131/3055 codelist/agency pairs 243 code types; 266 agencies
4435 channel 16 payment channels
RFF reference code to the source document
1153 reference codes 707 types of codes
TAX
5153 tax names 46
5279 tax rate ID 9999 see national tables
FII financial institution of bank account numbers
3035 party function (role) 490 roles or relationships
The financial institution
1131/3055 codelist/agency pairs 243 code types; 266 agencies
The branch of the fin. institution:
1131/3055 codelist/agency pairs 243 code types; 266 agencies
MOA monetary amounts for some control totals
5025 monetary qualifiers 496 kinds of amounts.
4405 Status description code 94 statuses, debits, credits etc.
CCI accounting, legal etc. characteristics
Measuremt details
6313 attribute codes 219 attributes you might track
Product characteristics
1131/3055 codelist/agency pairs 243 code types; 266 agencies
CAV association characteristic values
1131/3055 codelist/agency pairs 243 code types; 266 agencies
Then, follows some more control total sets, just like the ones above
for the file, with QTY/UOM pairs, RFF refs, DTM sets, and MOA sets.
There.
All of that, to post a journal entry. It took me 3 hours just to
count all these possible metadata that are allowed in the ENTREC
message. The number of permutations? There are 120 billion just
inthe first 5 lines (beginning of message above). The total
possible message layouts is Quadrillions of possible formats
for each of the 6 billion people on earth. If they each used
a million formats per second, for the rest of their lives they
would never exhaust their possible metadata formats.
Admittedly it is a marvelous technology. Like I said many time,
it would be usable if EBXML published a sensible, usable subset.
I'm not trying to break the EDIFACT formats. But EDIFACT is
*totally unusable* until somebody picks out a core subset and
resolves it into a single UML model with a scope of a couple
of thousand words. That is what xCBL has done. Isn't it?
The fundamental problem of EDI and ebXML is that you think
you can have a continuous, elastic vocabulary and grammar.
You're all wrong. You can't.
The fact is, you have to declare an EDI-Light because otherwise
the small business community is too fragmented to converge
around any subset and as a result, they are converging around
the new, crummier vocabularies. Doesn't that bother you?
There has to be a stairstep, *real soon*, in EDI vocabularies.
TOdd
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC