AR/AP revisions to Core Component Types and content models
2001/12/17

1. Id. Type The ebXML Identifier.Type requires a mechanism for globally disambiguating and addressing, besides "Identification.Scheme.Name", and "Identification Scheme.Agency". These assume both parties already agree on Identification Schemes, i.e. a controlled universe of providers of Identification Schemes with a central controller someplace, of the namespace. 

The definition of Identifier. Type is as follows,

A character string to identify and distinguish uniquely, one instance
of an object in an identification scheme from all other objects within
the same scheme together with relevant supplementary information.

Children: 

Identifier. Content (000102)
Identification Scheme. Name (000103)
Identification Scheme Agency. Name (000104)
Language. Code (000075)

General Ledgers and AR/AP systems use Identifiers ubiquitously for thing such as party, product, employee, etc.  There are internal namespaces, trading parties' namespaces as well as public "Agency" namespaces.  The need for general-purpose lists is fundamental to the requirements of accounting software such as the ARAP project. Accordingly we create a new Id.Type which adds these Child elements:

Id.Name - name of the thing represented by Identifier.Content
Id.Version.Text - version of Id.Name or Identification.Scheme
Id.ParentId.Text - Identifier of the parent of this item
Id.Balance.Amount - monetary balance of the Party,etc. after this GL Entry.
Id.BalanceCurrency.Code - currency code of the Balance
Id.SchemaUri.Text - RFC 2396 URI to the schema
Id.DataUri.Text - RFC 2396 URI to the service or resolver

The URI's are necessary to allow people to use registries and directories for people, companies, products, organizational units, etc. that do not exist in value domains of the "Agencies" in the UN/CEFACT "Scheme Agency. Name" namespace.

RFC 2396 URI addressing, with query component, can represent an object in local or network applications, filesystems, SQL databases, etc. as well as the usual SMTP, HTTP, etc.  This is an electronic address.  We have physical, telecoms, etc. addresses in Core Components. We need URI addresses, too.

The support for private, unregistered value domains exists within smaller collaborations and trading communities who don't disclose their "Schemes" to the public visibility, by registering as an "Agency" in Brussels or Washington DC, etc. Companies sometimes use their own product Ids on interactive web services with trading partners. This usage is part of the problem domain of EBTWG and semantic support should not be omitted. 

There are issues of privacy, as well as fair access to markets of suppliers and distribution. Users need the flexibility to select their own providers of list information, and these metadata are necessary for internal integration (A2A) such as transaction journals as well as B2B BPs. 

Private value domains for Identifiers are essential in A2A integration; any internal value domains such as charts of accounts, budget or organization units, etc.  

We anticipate some segment of users will support internal and external Codes and Code Lists with the above Id. Type, using its URIs for schema and data.

A reasonable alternative might be to create another identifier CCT which to supports the countless private or shared value domains. However, no such CCT is provided and indeed the name "Identification Scheme" which is a universal concept in data management, should be qualified if the current constraint is attached.

2. Doc. Type The 16 native ebXML representation terms and their underlying 11 CCT (core component types) are at a very general, low-level grain; however, they do include Code. Type and Identifier. Type which are considerably sophisticated, and far beyond mere software datatypes.  Accounting systems maintain data from every source in business, and rely on documents ubiquitously.  

Documents have well-known attributes. The ARAP project decided to invent a new CCT for "document" as follows,

General purpose struct. for business documents (including ordinary text as well as XML or other electronic documents) in accounting systems.

Children of Doc.Type: 

Doc.Type.Name - The name of the document (e.g. invoice, order, etc.)
Doc.TypeVersion.Text - version number of the Doc. Type. Name 
Doc.TypeSchemaUri.Text - RFC 2396 URI to the schema
Doc.Number.Text - Invoice number, PO number, etc. 
Doc.DateTime.Content - (same as ebXML DateTime.Content)
Doc.DateTimeFormat.Text - (same as ebXML DateTimeFormat.Text) 
Doc.Text - The whole document
Doc.Uri.Text - RFC 2396 URI to the original document
Doc.Signature.Text - hash or signature authenticating the document.

3. Implementation note regarding endless loops or unnecessary functionality depth.  AR/AP project adopts all Core Components without modification but notes that endless loops occur at numerous places in the content model.  Wherever Code or Identifier are  used, Code contains Identifier, and Identifier contains Language Code, which themselves contain more codes forever.  It is anyways, unnecessary to use the full class of Code.Type, Text.Type etc. to specify a choice from a universally-understood value domain such as currency codes, language codes, etc. and accordingly they should be passed between business partners as strings:

Example of endless loop, occurs in many circumstances if you interpret "Code" literally:

Date Time. Type   -- shown in table 6-1 has children,
   Date Time. Content
   Date Time. Format. Text   --shown in table 6-1 has children
      Text. Content
      Language. Code
         Code. Content
         Code List. Identifier   -shown in table 6-1 has children
            Identifier. Content
            Identification Scheme. Name
            Identification Scheme Agency. Name
            Language. Code
               Code. Content
               Code List. Identifier             XXXXXXX LOOP FOREVER
               Identifier. Content
               Identification Scheme. Name
               Identification Scheme Agency. Name
               Language. Code                    XXXXXXX LOOP FOREVER
         Code List. Agency. Identifier
            Identifier. Content
            Identification Scheme. Name
            Identification Scheme Agency. Name
            Language. Code
               Code. Content
               Code List. Identifier             XXXXXXX LOOP FOREVER
               Identifier. Content
               Identification Scheme. Name
               Identification Scheme Agency. Name
               Language. Code                    XXXXXXX LOOP FOREVER
         Code List. Version. Identifier
            (SAME AS ABOVE.)
         Code. Name
         Language. Code
            (SAME AS ABOVE.)

4.  Implementation note regarding Date and Time.   Date and Time should be intrinsic semantic types (CCTs), in addition to DateTime. Type.  There are 16 Permissible Representation Terms, Table 6-3, including Date and Time.  Many infrastructures support Date and Time natively including XML Schema. Users and applications use them. CCs are business vocabulary. The DateTime CCT is defined as "a particular point in the progression of time" (That's fine, of course. ) But a Time may recur daily, etc. A date may also recur but more importantly, vast numbers of BPs and business relationships are based only on Date.  Most of the world's operating systems and platforms do NOT today support the entire range of ISO 8601 format templates. Legacy applications espec. SMEs need the three data types, separately.

At the end of the day, applications which understand ISO 8601 Date Time will have no problem parsing a Date, or a Time. But the converse is not true.  Thus, to compress all three datatypes into one CCT (Date Time. Type) tempts implementers to add two CCT Types Date and Time, to their file of Core Components, leading to competitive advantage, and incompatibility.