Archive Notice: This page preserves the original work of Todd Boyle on general ledger architecture and distributed accounting (1997-2010), restored 2026 by The Ledgerism Brief. We are not affiliated with any accounting standards body. Original work © Todd Boyle. Visit The Ledgerism Brief for current editorial coverage of CPA practice, audit, M&A quality of earnings, and digital asset accounting.
Author Topic:   Eight Levels of Core Components - narrative
Todd Boyle

[This message was edited by Todd Boyle on Monday, 18 February 2002 at 22:31.] edited 3/27/02-TB


Posts: 115 | From: Kirkland, WA USA | Registered: Tuesday, 03 April 2001
Todd Boyle
 
posted Tuesday, 19 February 2002 20:02

The latest release of ebXML Core Components Technical Specification was
announced and posted as an attachment, in the mailing list Feb. 2, 
http://lists.ebtwg.org/archives/ebtwg-ccs/200202/msg00089.html  
(now at http://www.unece.org/cefact/ebxml/ebXML_CCTS_Part1_V1-8.pdf 
)

Core Components Technical Specification (CCTS) meta model for
the expression of business meanings, defines as many as eight distinct layers of metadata,

1. Primitive types (string, decimal, etc.) which are used in
2. Content and Supplementary Components " "
3. Core Component Types (CCT's) " "
4. Representation Terms " "
5. Data Types " "
6. Core Components (CC's), and " "
7. Business Information Entities (BIE's) " "
8. Assembly Documents

Here is how the GLIEs database stores Core Components. 

This diagram communicates what is going on in the ARAP Project' registry of GLIEs which
are core components for basic accounting and economic events stored in an Access MDB:
(The MDB file is in the DOWNLOAD at http://www.arapxml.net/GLcoreComponentsV095.htm)

We chopped out complexity at the lowest level (Level 7 and 8) by ignoring those object classes
implied by the names of the Supplemental Components. (Table 8-2 at the end of the CCTS document).
This was pragmatic, since it is impractical to implement BIEs correctly according to the CC technical specification which calls for Constraints Language, without having a full commercial Registry/Repository. 
Accordingly we expect zero adoption of RegReps and Constraint Language by individuals or SMEs
in the short term or mid term. 

CCTS prescribes the CCT classes that are allowable and implies that no other CCTs are allowable.  This puts a Glass Floor so that we cannot add any datatypes or business types below that floor.  That is OK.  We can see the Supplemental Components. But we don't have the rest of the classes or objects to which they apparently belong, and we can't do anything with them! So I say, they are nothing but a string, number, binary, etc. as shown in Table 8-2 at the end of the CCTS.

The benefit is, we are able to express some Core Component semantics in a way that we are ensured, can be implemented in the RegRep without much change. But the penalty is, we aren't really compliant with the CCTS. To achieve that we would have to partner with XML Global or one of the other RegRep providers.

Todd

............quoted material follows from my earlier post.

The AR/AP project published some draft information entities for general
ledgers in December at http://www.arapxml.net/GLcoreComponentsV091.htm
The goals for this are http://www.arapxml.net/requirements.htm

We reformulated the December GLIEs, because they used unapproved
CCTs. I invented two CCTs.  That was bad.  We realized nobody 
would use the schema.  Furthermore, the Core Components workgroup
added URI support to their Identifier Type.  That enabled us to use the 
native Identifier .Type instead of our custom ID.Type.  There were 
actually six alternative solutions and the decision was made by 
reference to the requirements of the overall project decision grid.

[This message was edited by Todd Boyle on Tuesday, 19 February 2002 at 22:15.] and 3/27/02


Posts: 115 | From: Kirkland, WA USA | Registered: Tuesday, 03 April 2001