The Core Components Technical Specification (CCTS) is a meta model for
the expression of business meanings, that are both machine readable and
human readable, internationally. This is different from any other
system of business semantics.

If successful, the CCTS will allow *any* context relative terms or
jargon from any region or language, to be pinned down to exact definitions
with normative meanings.

Core Components will have unique names, as well as UIDs (unique
identifier numbers) but the architecture should not be confused with
other e-business vocabularies that are actually, flat namespaces. The
CCTS 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 are some examples of CCT's. (there are actually 11 CCTs):

CCT Content and Supplementary Components (children)
--- ----------------------------------------------

Text. Type "Text. Content; Language. Code"

Amount. Type "Amount. Content; Amount Currency. Identification. Code"

Code. Type "Code. Content; Code List. Identifier; Code List. Agency. Identifier; Code List. Version. Identifier; Code. Name; Language. Code"

Date Time. Type "Date Time. Content; Date Time. Format. Text"

Identifier. Type "Identifier. Content; Identification Scheme. Name; Identification Scheme Agency. Name; Language. Code; Identification Scheme. Uniform Resource Identifier; Identification Scheme. Data. Uniform Resource Identifier"

--- ----------------------------------------------

The primitive type of "Text.Content" is string. The primitive type of
Amount.Content is numeric. This is the point of departure, where CCTS
builds upon any given software development language or platform.

There are 16 Representation Terms that are based on CCT's. Actually they
are very close to CCTs. They repeat the names of every one of the 11 CCTs,
and add five more such as "Name" which is just a special case of Text.Type.

The Data Types are just the same thing as Representation Terms, except
having restrictions on range of values and restrictions on format.

--------

Now you have the framework to create Core Components which have NO
CONTEXT and cannot be used in business processes. Every Core Component
will be replicated in the Registry to create a BIE of the same name.
This is vaguely similar to how the Representation Terms are just
extensions of CCTs. To create a BIE in the registry, classification
MUST be encoded for each of the eight context classifications (Business
Process, Product, Industry, Geo, etc.) and cardinality for child
elements is added. When a CC is used to create a BIE with a minimum of
refinement or modification, it would have values of "All Contexts" for
each context attribute except Official Constraints (which would be
"None"). A value of 1 might be applied to each child element for
MinOccurs and MaxOccurs.

---

This architecture allows the entire vocabulary of terms that are
actually used in verbal and paper business exchanges, even though they
would be too ambiguous, if used within a flat namespace. Core
Components can be created for things like "AmountDue" which are really
only a partial semantic unit, and would be too ambiguous to be used by
computers, within any flat namespace.

Core components can use AmountDue, because Core Components has another
layer of abstraction to work with. An AmountDue is a very useful atomic
piece of semantics, which might be defined as,

AmountDue.Amount: "An amount having the general connotation of being
outstanding and payable from one party to another party, and not
yet settled, at a particular point in time."

This AmountDue might be a Basic Core Component that is simply, an
Amount.Type with a new name. Obviously somebody other than myself will
create these definitions, within the EWG harmonization teams efforts.

A core component must be a discrete concept that is universal and
without business process context. The concept of amount due, might be
usefully refined further, creating additional Basic Core Components, for
example,

ItemAmountDue.Amount: "An amount due on a discrete item...
TotalAmountDue.Amount; "The total amount due on all of the discrete
ItemAmountDue.Amount's within a business document such as an invoice."

We might also see these BCCs aggregated into Aggregate Core Components,
such as

TotalAmountDueAndPayable.Details
TotalAmountDue.Amount
DueDate.Date

Finally, users would use the above Core Components to create BIE's to
perform Business Process such as Premium Quotation, within the insurance
Industry context, in the US Geo. context, etc. as well as bazillions
of other contexts. (Registry designers are pulling out their hair,
trying to make sure the BIEs don't explode into an exponential number
of discrete components having almost identical semantic meanings.)

BIEs are used within business documents. The Assembly constraint
language defines the numerous structures necessary to articulate a
business document composed of any number of BBIEs and ABIEs. This looks
suspiciously like a database schema reverse engineered out of XML
Schema, because what you have is a syntax-neutral, narrative and textual
way of describing how lots of BIEs are grouped and constrained and
minoccur/maxoccurr'd into a business document. At some point you just
want to say, "Hey I learned XML Schema, and I have decided not to use
any other syntax besides XML. Why do I have to learn this Constraint
Language? Is there some kind of runtime or what?" And the answer
is yes. The Registry/Repository uses this constraint language. You
can store BIEs in a registry repository, but not document formats.

Immense numbers of documents definitions can be stored in a repository
(as Assemblies). They can be referred to by UID. Future ebusiness
exchanges may consist of a bunch of UID-value pairs. The UID for
the Assembly, followed by the UIDs of the values in the form. That's
about as terse as you can get, on the wire.

Although the CC meta model is substantially more complex than the flat
namespace of vocabularies such as EDIFACT, X12, OAGIS, XCBL, ACORD,
etc., it has the merit of reusing semantic building blocks in much the
same way as the human mind, and it is machine computable so, I regard it
as quite an advancement,

I hope I have not erred in any of this. The CCTS itself is far more
precise and this is just a quick, informal view.

Here is how the GLIEs database stores Core Components. 

This diagram communicates what is going on in the Access MDB registry of GLIEs.
(The MDB file is in the DOWNLOAD at http://www.arapxml.net/GLcoreComponentsV091.htm)

We are gaining practicality, 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. 

Since the CCTS does not allow us to create our own CCTs and Representation terms, it is quite
restrictive. There is a Glass Floor. You cannot change the design below.  You cannot do OOA/OOD and OOP without the ability to create and use base classes.  The 16 base classes in the CCTS may be adequate for B2B message but they are not adequate for software development, or even internal EAI.

We are also chopping 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).  CCTS prescribes the Content and the Supplemental Component for each CCT.   We can see the Supplemental Components, having names like "Code List. Agency. Identifier".  But we don't have any documentation for any class called Code List, or what its base class "Identifier" might be.  Since we don't know the models for these classes or objects to which they apparently belong, 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.

The benefit of these compromises is that 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 Core Componetns Technical Specification. To achieve that we would have to partner with XML Global or one of the other RegRep providers.

Todd

The goal is to serve as a "secretary" that maintains a comprehensive
history of economic commitment and event information. SMEs are, today,
manually entering most of their documents. The goal of my project is
to get information in and out of the computer, and exchange it with
trading partners--that is all. THe goal is to provide usable
interfaces, not to automate any action or decision. Bluntly, if
you give SMEs an accounting system with reliable messaging and a
public standard vocabulary, they will have *no problem* understanding
what to do with any invoice, PO, ship notice, etc.

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

The December GLIEs are being reformulated because they used unapproved
CCTs. I invented two CCTs. That was bad.

So, we have now created ACC's (Aggregate Core Components) for our
identifier and document. (formerly Id.Type and Doc.Type, now they are
Id.Details and Doc.Details. These are for internal use by the owner so
I have excused myself from Oxford spelling. I'm principally interested
in aligning internal data dictionary with the standard external CC
vocabulary, and in using ebXML runtimes as the processing platform for
local transactions. That means, when we see the whites of the e-
business documents' eyes we need this GL schema to map them into. (when
BCPMC BOTLs happen, presumably my application will be well positioned as
an accounting provider. That is the whole point.)

Reformulating the GLIEs (General Ledger Information Entities) for GL
Entry to use our ACC's (Aggregate Core Components) Doc.Details and Id.
Details, instead of our unapproved CCT's, Doc.Type and Id.Type is not
so easy.

Our thinking is utterly simple. We just want to have flat "GL Entry"
rows, with dates/amounts and a bunch of specifically named attributes on
each row for the most common classifications that occur in small
business systems.

We really need to reuse a lower-level class in a natural way, by
referring to it in the third term of the Dictionary Entry Name (DEN)
But the 3rd term is reserved exclusively for one of the 16
Representation Term in Core Components specification, or, the word
"Details" if the component is an Aggregate.

If we do not create our own CCTs and Representation terms, it is quite
restrictive. There is a Glass Floor. you cannot change the design
below.

So the only direction to achieve more levels (without getting into
Constraints Language) is just to copy the "Id. Details" multiple times,
and rename them:

GL.OrganizationUnit.Id becomes OrganizationUnit. Details
GL.Party.Id becomes Party. Details
GL.ProductService.Id becomes ProductService. Details
GL.Project.Id becomes Project. Details
GL.Job.Id becomes Job. Details
GL.CostCenter.Id becomes CostCenter. Details
GL.Employee.Id becomes Employee. Details
GL.Fund.Id becomes Fund. Details
GL.Program.Id becomes Program. Details

This may be reasonably compliant the definition of a Core Component,
because, although it uses exactly the same Core Component with different
names, they have different semantic meanings.

But we are screwing ourselves by making these entirely separate classes
in the ARAP software --there would be no indication whatsoever in the
GLIEs registry that these are the same component, that they are
inheriting the same class. The XML Schema representation of GL Entry
would be much bigger, and so would the UML and executable code of the
ARAP Submission.

Another possibility is just to make these Identifiers a text field.

GL.OrganizationUnit.Id becomes GL.OrganizationUnit Id. Text
GL.Party.Id becomes GL.Party Id. Text
GL.ProductService.Id becomes GL.ProductService Id. Text
GL.Project.Id becomes GL.Project Id. Text
GL.Job.Id becomes GL.Job Id. Text
GL.CostCenter.Id becomes GL.CostCenter Id. Text
GL.Employee.Id becomes GL.Employee Id. Text
GL.Fund.Id becomes GL.Fund Id. Text
GL.Program.Id becomes GL.Program Id. Text

However, if you then have an XML instance document containing GL
Entries, it could no longer stand alone. For every informational
need such as Party, Product/service, etc., only an identifier
could be included in the GL Entry XML document. You would need
a supporting message with all the reference data. Applications
that don't work this way, for example, needing to literally put
the name of Customer in the transaction line, may be unable to
use the GL Entry aggregate.

So, we might just use the new, native CCT for Identifier.Type,
which now has URI's for internal value domains.

GL.OrganizationUnit.Id becomes GL.OrganizationUnit. Identifier
GL.Party.Id becomes GL.Party. Identifier
GL.ProductService.Id becomes GL.ProductService. Identifier
GL.Project.Id becomes GL.Project. Identifier
GL.Job.Id becomes GL.Job. Identifier
GL.CostCenter.Id becomes GL.CostCenter. Identifier
GL.Employee.Id becomes GL.Employee. Identifier
GL.Fund.Id becomes GL.Fund. Identifier
GL.Program.Id becomes GL.Program. Identifier

That's fine but then, you have just lost the capability of the additional
4 elements we invented for our ID. Details, which are not adopted by
the Core Components group:

Id. Entity. Name ;0;1;3;30
Id. Version. Text ;0;1;4;30
Id. Parent Id. Text ;0;1;5;30
Id. Balance. Amount ;0;1;6;30

In other words you could not put the name of the customer or product in
the GL Entry instance anymore. It would have to go into a lookup table.
No choice would be available, in the GL Entry document format.

And you could not use Parent ID to express where an OrganizationUnit or
Project Identifier exists in a hierarchy, or include the balance of the
Customer or Product, etc., in the message. And, there would be not even
the slight flexibility to accommodate changing dimensions, which is
possible with a version id.

So, we are back to the kinds of hard questions that plagued the ARAPXML
effort last year. Obviously there is no magic bullet, that can maximize
every objective.

ArapXML creates specifically-named entities on the entry line, because
it has a particular application in mind (ARAP and small business
accounting). ArapXML places a high priority on immediate ease of use
and familiarity that can come from specifically named elements. We know
that Quickbooks, Peachtree have predominant market shares with only a
very few dimensions like customer, vendor and employees, and project,
inventory items.

XBRL GL does *not* create specifically named entities, perhaps, because
XBRL places a higher value on a universal, global structure than on
immediate ease of use or readability. Here is what XBRL GL puts on
their GL entry line:

identifierReference - Identification for customer, vendor, employee.
  identifierCode - Internal ID Number associated w identifierReference
  identifierTaxCode - Tax ID Number associated with identifierReference
  identifierDescription - Textual description of identifierReference.
  identifierType - Entity type: e.g., customer, vendor, employee.
  identifierAddress
    identifierStreet
    identifierCity
    identifierStateOrProvince
    identifierCountry
    identifierZipOrPostalCode