RE: Jon Bosak's suggestion that xCBL be adopted as theebXMLBusinessDocument framework

[Todd Boyle <tboyle@rosehill.net>]

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