CCTS and JSON Discussion paper

Kenneth Bengtsson

Erlend Bergheim

Difi Norway

G. Ken Holman

Crane Softwrights Ltd.

$Date: 2016/10/17 18:50:10 $(UTC)


Table of Contents

1. Overview
2. Current XML-based approaches to JSON
3. UN/CEFACT Core Component Technical Specification
3.1. CCTS component review
3.2. Portability with XML applications
4. Marshalling CCTS to JSON
4.1. BIE names
4.2. Document ABIE expression
4.3. ASBIE expression
4.4. BBIE expression
4.5. Extension expression
5. Unmarshalling JSON to CCTS
5.1. Overview of unmarshalling
5.2. JavaScript syntax
5.3. Python syntax
6. Example serializations of business documents
6.1. Examples overview
6.2. UBL-Invoice-2.1-Example-Trivial.json
6.3. Modified invoice example
6.4. UBL-TransportationStatus-2.1-Example.json
7. Moving forward

1. Overview

In a recent UBL TC teleconference it was observed that a JSON instance is more in line with an XML instance than it is with an XSD schema.

The UBL specification is a model of possible XML instances reflecting the business objects possible for a given document, and that model is expressed in XSD. The XML angle brackets express a single instance (hence the name!) of a set of CCTS-defined business objects needed to be exchanged between business partners.

So, to state the obvious, what is exchanged between business partners is that XML serialization of the given set of business objects of a given abstract business document. The XSD only exists as a guide for creation and a tool for validation. The XSD can be used by sender and receiver to know outside of a given application that the structure is as dictated by the committee, but the applications are simply working with the XML serialization in order to get the content.

This glosses over the XSD concept of the PSVI (post schema validation information set) that can be used by an application to interpret the lexical XML strings as known data types so that an application can process the data values instead of converting them. JSON has built in a limited number of data types that are accommodated by this specification.

So in the same way an application prepares XML from CCTS objects, in a JavaScript world it would prepare a JSON expression from CCTS objects. Accordingly, there would also be a constraint expression in JSON Schema as a parallel to the XSD.

Therefore, what was proposed in the TC meeting is that what is specified in OASIS is the marshalling and unmarshalling of a set of CCTS objects to and from JSON syntax. No reference to XML, only to BBIEs, ASBIEs, Document ABIEs, and the Core Component Data Types and Supplementary Objects. That way the committee is framing the discussion in business objects that are up to the developer to express, only giving guidance on how to serialize those objects as a JSON stream for interchange.

Such a strategy also divorces the progress of these concepts from the progress of UBL 2.2. It won't hamper the release schedule of UBL 2.2.

For reference, this proposal uses the draft ISO/IEC 21778:2016, which is just an ISO cover over specification ECMA-404 (how would one know if they couldn't find it?):

This paper assumes the marshalling and unmarshalling happens directly to memory structures of the given language, so it is most likely that the developer will simply work with the information in the memory structures we guide them to use to express BBIEs, ASBIEs and Document ABIEs.

This proposal attempts to justify what might appear at first glance to be arcane and verbose syntax. But a rigourous approach should be appreciated by programmers. The objective is for clear and unambiguous machine-to-machine exchange of the content, without the brevity that might be appreciated in a person-to-person exchange.

2. Current XML-based approaches to JSON

One thing this CCTS focus allows is for us not to be constrained to XML syntax where it collides with JavaScript or JSON syntax. A good example is in namespaces where XML uses a colon, but the colon cannot be used when using dot notation for JSON structures. The same is true for the @ sign used by JSON-LD, http://www.json-ld.org, for attributes.

It is not necessary to preserve the namespaces concept, but for completeness this proposal accommodates the expression of namespace URI strings if this is important for unambiguous identification. How these strings are used is outside the scope of this specification.

This proposal treats CCTS components and supplementary components simply by their name, not as namespace-qualified XML elements or as XML attributes.

3. UN/CEFACT Core Component Technical Specification

3.1. CCTS component review

From a model perspective, the UN/CEFACT Core Components Technical Specification (CCTS) 2.01 http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS_V2-01_Final.pdf is used to define a class of business documents by specifying the available components to be used. An ABIE (aggregate) component specifies a collection of constituent components of ASBIE components (associations to other ABIEs) and BBIE components (basic indivisible portions of content). The Document ABIE is simply an ABIE that is not defined in the common library. A Document ABIE specifies the components at the apex of a business document. A Library ABIE specifies the components comprising an ASBIE. An assumption is that an ASBIE can be defined by a Library ABIE and not by a Document ABIE.

From an instance perspective, a given business document is comprised of its Document ABIE with its indivisible BBIEs and with its (divisible) ASBIEs that each have their own BBIEs and ASBIEs.

Each BBIE is defined by its data type. The available Core Component Types are summarized in Chapter 8 of the CCTS 2.01 specification. Each type has a mandatory content component and a number of optional supplementary components. The interpretation of the content is informed by the values of its given supplementary components. The data type content and supplementary component values are, ostensibly, either numbers, strings or Boolean values. Interpreting the strings to be abstract concepts such as date and time is up to the program.

A name used in any given group is not prohibited from also being used in another group. For example, in the UBL vocabulary there is a Library ABIE named "Location" and a BBIE named "Location". This specification provides a mechanism, not based on namespace URI strings, to disambiguate names that might be sibling name/value pairs in an object.

A vocabulary based solely on CCTS has properties that are accommodated in this specification without needing also to accommodate the generalities of arbitrary XML markup. That distinction makes this serialization quite different from the serializations proposed in the community for XML documents.

For the purposes of this document, the http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.0/Business-Document-NDR-v1.0.html#S-DICTIONARY-INFORMATION section of the OASIS Business Document Naming and Design Rules Version 1.0 constrains how the CCTS components are defined.

3.2. Portability with XML applications

For portability between JSON applications and XML applications acting on the content, some assumptions about the CCTS model are presumed.

All BIE names shall be valid XML no-colon names, as used for the local name of an XML Namespace qualified name.

All BBIE content and supplementary component names are abbreviated in this specification by eliding all period and space characters that would otherwise interfere with JSON dot notation or with XML names.

Certain BBIE data type content must be constrained by XML Schema Part 2: Datatypes (XSD) for portability with XML tools. Boolean values must only be expressed as "true" and "false", even though XSD also supports "1" and "0" for these values. Date and time values must be expressed using ISO 8601 as described by XSD. Binary object values must be expressed by XSD base64Binary in a string.

4. Marshalling CCTS to JSON

4.1. BIE names

There are four groups of names made from the names of the Document ABIEs, the names of BBIEs, the names of both Library ABIEs and the ASBIEs that point to them, and the names of extension scaffolding and metadata items. In fact there are many groups of Document ABIEs as each Document ABIE is in a group of one of only itself.

Note

These four groups of names are referenced in http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.0/Business-Document-NDR-v1.0.html#S-NAMESPACES for XML serialization.

The namespace URI values applicable to all of the names found outside of foreign extensions in a given business document may be found as name/value pairs in the Document ABIE object for that document.

When two name/value pairs in a given JSON object have the same name but one of them is an ASBIE and the other is a BBIE, each name must be suffixed with, respectively, either "_S" or "_B" as appropriate and other names not in conflict shall not be suffixed. If all names of name/value pairs in a given JSON object are distinct, then all of the names shall have no suffix.

Note

A consequence of these rules is that when a CCTS-defined business vocabulary has no ABIE where a member ASBIE and a member BBIE have the same name, every possible JSON serialization will have no name suffixes.

Note

Users of a CCTS-defined business vocabulary will know where these rules may come into play before writing the application and so, for any given version of the vocabulary, an application writer will know when it may be necessary to check for a given name with either a suffixed name or a name without a suffix. If a future version of the vocabulary introduces a potential name collision, legacy applications may not be in a position to recognize the new use of a suffix. However, from a maintenance perspective, the application developer need only look for the use of those names where the collision has been introduced.

4.2. Document ABIE expression

Each Document ABIE shall be represented as an object containing a single name/value pair.

The name of that pair shall be the local name of the Document ABIE.

The value of that pair shall be an object. The object may contain the following name/value pairs for documentary purposes, and for completeness should do so:

  • name "_D" with the value of the Document ABIE namespace URI;

  • name "_S" with the value of the ASBIE namespace URI (that is, the Library ABIE namespace URI);

  • name "_B" with the value of the BBIE namespace URI; and

  • name "_E" with the value of the extension namespace URI (when extensions are being used).

The Document ABIE object shall contain name/value pairs all of the ASBIE and BBIE members in actual use of those available as specified by the Document ABIE.

The Document ABIE object may contain a single name/value pair representing the apex of the scaffolding of foreign extension content. This name is defined by a specification of a given business vocabulary and may be different than that of other business vocabularies. However, all document types in a given business vocabulary should be using the same name for the apex of the scaffolding of foreign extension content.

Note

A Document ABIE has no associated metadata and so there is no need to accommodate anything akin to an attribute of an XML element.

An example of a serialized Document ABIE with some content elided by the ellipsis for brevity, leaving two BBIEs and an ASBIE that has two BBIEs:

{"Invoice":
 {
 "_D":"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2",
 "_S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "_B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "ID":[{"IdentifierContent":"123"}],
 "IssueDate":[{"DateTimeContent":"2011-09-22"}],
 "InvoicePeriod":[{
  "StartDate":[{"DateTimeContent":"2011-08-01"}],
  "EndDate":[{"DateTimeContent":"2011-08-31"}]
 }],
...
}}

4.3. ASBIE expression

Each sequence of one or more consecutive ASBIE components of the same name shall be serialized as a single name/value pair of its parent ASBIE or Document ABIE JSON object.

The one name for that pair shall be the name of the ASBIE. Only when there is another name/value pair for a non-ASBIE construct in the same object that has the same name as the ASBIE, the name of the ASBIE shall be suffixed with "_S".

The one value for that pair shall be a JSON array of one or more objects, each object representing, in array order, the sequence order of the consecutive ASBIEs.

Each ASBIE object in the array shall have as its name/value pairs all of the ASBIE and BBIE members in actual use of those available as specified by the ABIE that defines the ASBIE.

Note

An ASBIE has no associated metadata and so there is no need to accommodate anything akin to an attribute of an XML element.

Some examples of serialized ASBIEs … a party and two invoice lines:

  •  "AccountingSupplierParty":[{
      "Party":[{
       "PartyName":[{
        "Name":[{"TextContent":"Custom Cotter Pins"}]
       }]
      }]
     }]
  •  "InvoiceLine":[{
      "ID":[{"IdentifierContent":"1"}],
      "LineExtensionAmount":[{"AmountContent":100.00,
       "AmountCurrencyIdentifier":"CAD"}],
      "Item":[{
       "Description":[{"TextContent":"Cotter pin, MIL-SPEC"}]
      }]
     },{
      "ID":[{"IdentifierContent":"2"}],
      "LineExtensionAmount":[{"AmountContent":200.00,
       "AmountCurrencyIdentifier":"CAD"}],
      "Item":[{
       "Description":[{"TextContent":"Axel"}]
      }]
     }]

4.4. BBIE expression

Each sequence of one or more consecutive BBIE components of the same name shall be serialized as a single name/value pair of its parent ASBIE or Document ABIE JSON object.

The one name for that pair shall be the name of the BBIE. Only when there is another name/value pair for a non-BBIE in the same object that has the same name as the BBIE, the name of the BBIE shall be suffixed with "_B".

The one value for that pair shall be a JSON array of one or more objects, each object representing, in array order, the sequence order of the consecutive BBIEs.

Each BBIE shall have a name/value pair whose name is the core component type content component appropriate to the primary or secondary representation term being used, and whose value is the value of the business object.

Each BBIE may have as many name/value pairs with the names and values of optional supplementary components of the given instance of the Core Component Type.

The JSON names shall be derived from the approved CCTS 2.01 core component type content and supplementary component names by removing all periods and spaces. This is summarized as follows:

Table 1. CCTS 2.01 approved core component type content and supplementary components for permissible representation terms

Permissible primary and secondary representation terms

Approved content and supplementary components

Amount
AmountContent
AmountCurrencyIdentifier
AmountCurrencyCodeListVersionIdentifier
BinaryObject
Graphic
Picture
Sound
Video
BinaryObjectContent
BinaryObjectFormatText
BinaryObjectMimeCode
BinaryObjectEncodingCode
BinaryObjectCharacterSetCode
BinaryObjectUniformResourceIdentifier
BinaryObjectFilenameText
Code
CodeContent
CodeListIdentifier
CodeListAgencyIdentifier
CodeListAgencyNameText
CodeListNameText
CodeListVersionIdentifier
CodeNameText
LanguageIdentifier
CodeListUniformResourceIdentifier
CodeListSchemeUniformResourceIdentifier
DateTime
Date
Time
DateTimeContent
DateTimeFormatText
Identifier
IdentifierContent
IdentificationSchemeIdentifier
IdentificationSchemeNameText
IdentificationSchemeAgencyIdentifier
IdentificationSchemeAgencyNameText
IdentificationSchemeVersionIdentifier
IdentificationSchemeDataUniformResourceIdentifier
IdentificationSchemeUniformResourceIdentifier
Indicator
IndicatorContent
IndicatorFormatText
Measure
MeasureContent
MeasureUnitCode
MeasureUnitCodeListVersionIdentifier
Numeric
Value
Rate
Percent
NumericContent
NumericFormatText
Quantity
QuantityContent
QuantityUnitCode
QuantityUnitCodeListIdentifier
QuantityUnitCodeListAgencyIdentifier
QuantityUnitCodeListAgencyNameText
Text
Name
TextContent
LanguageIdentifier
LanguageLocaleIdentifier

Some examples of serialized BBIEs … an identifier, a date and two notes:

  •  "ID":[{"IdentifierContent":"123"}]

  •  "IssueDate":[{"DateTimeContent":"2011-09-22"}]

  •  "Note":[{"TextContent":"Test",
      "LanguageIdentifier":"en"},
     {"TextContent":"Tester",
      "LanguageIdentifier":"fr"}]

4.5. Extension expression

When a business document contains foreign content not defined by the business vocabulary, this content is placed under a single apex containing all of the scaffolding of all foreign extension content. The name of this apex is defined by a specification of a given business vocabulary and may be different than that of other business vocabularies. However, all document types in a given business vocabulary should be using the same name for the apex of the scaffolding of foreign extension content.

This apex name is used as the name of the name/value pair of the Document ABIE object. Only when there is another name/value pair in the same object that has the same name as the extensions apex, the name of the extensions apex shall be suffixed with "_E".

The extensions apex name/value pair in the parent Document ABIE shall have as its value an array of extensions. Each member of the array shall be an object. Each object may have any number of name/value pairs of extension metadata, whose names are defined by the vocabulary. Each object shall have a name/value pair with an agreed-upon name (e.g. in UBL this name is "ExtensionContent") whose value is the foreign content.

For the purposes of this document, the expression of foreign content is out of scope. Where a business document provides for content not defined by the business document, the JSON serialization of that content shall be agreed upon between trading partners. Given that the apex of an extension has a role similar to a document element, one could consider serializing an extension in a manner similar to serializing a Document ABIE.

5. Unmarshalling JSON to CCTS

5.1. Overview of unmarshalling

A JSON stream loaded into an application's variable will create in that variable the objects and arrays representing CCTS constructs.

An application will, typically, know all of the names of all of the possible business objects represented by the Document ABIE, the ASBIEs and the BBIEs. It will also know the name of the extensions apex.

An array member of the extensions apex name/value pair of a Document ABIE object will be an array of objects each containing a name/value pair for extension content with the name agreed upon by the community of users. The value is assumed to be foreign content agreed upon or unknown to trading partners within the community.

Otherwise, should it ever be necessary for an application to infer the processing of a given array member object, an object with every name/value pair having a value that is not an array of objects can be assumed to be a BBIE. An object that does have a name/value pair with the value being an array of objects can be assumed to be an ASBIE.

The examples in this section are copied from the interactive interfaces of the "node.js" interpreter and the "python" interpreter.

5.2. JavaScript syntax

This JSON representation support for CCTS objects fully supports the dot notation defined in JavaScript.

The JSON stream creates an object with a single name/value pair. The name of that pair is the name of the Document ABIE. The value of that pair is the object defining the contents of the Document ABIE comprised of BBIEs and ASBIEs.

Each BBIE and ASBIE must be addressed as a list that is guaranteed to have at the least a single member addressed with "[0]".

Note

Future versions of the business vocabulary may raise the cardinality of the object and so this approach is future proof to revisions. This approach is also consistent and is used without thought of cardinality and so should be easier for the programmer (if a little verbose).

The content of a BBIE is addressed as the object name/value pair with the name ending in "Content". Supplementary components of a BBIE are addressed by their name (compressed removing periods and spaces).

Some examples of dot notation syntax:

> obj.Invoice.Note[0]
{ TextContent: 'Test', LanguageIdentifier: 'en' }
> obj.Invoice.Note[1]
{ TextContent: 'Tester', LanguageIdentifier: 'fr' }
> obj.Invoice.Note[1].TextContent
'Tester'
> obj.Invoice.InvoiceLine[1].LineExtensionAmount[0].AmountContent
200
> obj.Invoice.InvoiceLine[1].LineExtensionAmount[0].AmountCurrencyIdentifier
'CAD'
> 

This approach also supports the object notation defined in JavaScript.

The same examples using list and object notation syntax:

> obj["Invoice"]["Note"][0]
{ TextContent: 'Test', LanguageIdentifier: 'en' }
> obj["Invoice"]["Note"][1]
{ TextContent: 'Tester', LanguageIdentifier: 'fr' }
> obj["Invoice"]["Note"][1]["TextContent"]
'Tester'
> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["AmountContent"] 
200
> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["AmountCurrencyIdentifier"]
'CAD'
> 

5.3. Python syntax

This approach fully supports the list and dictionary notation defined in Python.

The JSON stream creates a dictionary with a single name/value pair. The name of that pair is the name of the Document ABIE. The value of that pair is the object defining the contents of the Document ABIE comprised of BBIEs and ASBIEs.

Each BBIE and ASBIE must be addressed as a list that is guaranteed to have at the least a single member addressed with "[0]".

Note

Future versions of the business vocabulary may raise the cardinality of the object and so this approach is future proof to revisions. This approach is also consistent and is used without thought of cardinality and so should be easier for the programmer (if a little verbose).

The content of a BBIE is addressed as the dictionary name/value pair with the name ending in "Content". Supplementary components of a BBIE are addressed by their name (compressed removing periods and spaces).

Some examples using list and dictionary syntax:

>>> obj["Invoice"]["Note"][0]
{u'LanguageIdentifier': u'en', u'TextContent': u'Test'}
>>> obj["Invoice"]["Note"][1]
{u'LanguageIdentifier': u'fr', u'TextContent': u'Tester'}
>>> obj["Invoice"]["Note"][1]["TextContent"]
u'Tester'
>>> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["AmountContent"]
200.0
>>> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["AmountCurrencyIdentifier"]
u'CAD'
>>> 

Note

Observe how the Python list and dictionary syntax is identical to the JavaScript list and object syntax.

6. Example serializations of business documents

6.1. Examples overview

These examples are extracted from sample XML instances found in the UBL 2.1 distribution at http://docs.oasis-open.org/ubl/os-UBL-2.1/xml/.

For legibility the examples are indented. Indentation is insignificant white space and optionally can be eliminated from the file.

6.2. UBL-Invoice-2.1-Example-Trivial.json

{"Invoice":
 {
 "_D":"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2",
 "_S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "_B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "ID":[{"IdentifierContent":"123"}],
 "IssueDate":[{"DateTimeContent":"2011-09-22"}],
 "InvoicePeriod":[{
  "StartDate":[{"DateTimeContent":"2011-08-01"}],
  "EndDate":[{"DateTimeContent":"2011-08-31"}]
 }],
 "AccountingSupplierParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"TextContent":"Custom Cotter Pins"}]
   }]
  }]
 }],
 "AccountingCustomerParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"TextContent":"North American Veeblefetzer"}]
   }]
  }]
 }],
 "LegalMonetaryTotal":[{
  "PayableAmount":[{"AmountContent":100.00,
   "AmountCurrencyIdentifier":"CAD"}]
 }],
 "InvoiceLine":[{
  "ID":[{"IdentifierContent":"1"}],
  "LineExtensionAmount":[{"AmountContent":100.00,
   "AmountCurrencyIdentifier":"CAD"}],
  "Item":[{
   "Description":[{"TextContent":"Cotter pin, MIL-SPEC"}]
  }]
 }]
}}

6.3. Modified invoice example

This example has multiple BBIEs for "Note" and multiple ABIEs for "InvoiceLine":

{"Invoice":
 {
 "_D":"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2",
 "_S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "_B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "ID":[{"IdentifierContent":"123"}],
 "IssueDate":[{"DateTimeContent":"2011-09-22"}],
 "Note":[{"TextContent":"Test",
  "LanguageIdentifier":"en"},
 {"TextContent":"Tester",
  "LanguageIdentifier":"fr"}],
 "InvoicePeriod":[{
  "StartDate":[{"DateTimeContent":"2011-08-01"}],
  "EndDate":[{"DateTimeContent":"2011-08-31"}]
 }],
 "AccountingSupplierParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"TextContent":"Custom Cotter Pins"}]
   }]
  }]
 }],
 "AccountingCustomerParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"TextContent":"North American Veeblefetzer"}]
   }]
  }]
 }],
 "LegalMonetaryTotal":[{
  "PayableAmount":[{"AmountContent":100.00,
   "AmountCurrencyIdentifier":"CAD"}]
 }],
 "InvoiceLine":[{
  "ID":[{"IdentifierContent":"1"}],
  "LineExtensionAmount":[{"AmountContent":100.00,
   "AmountCurrencyIdentifier":"CAD"}],
  "Item":[{
   "Description":[{"TextContent":"Cotter pin, MIL-SPEC"}]
  }]
 },{
  "ID":[{"IdentifierContent":"2"}],
  "LineExtensionAmount":[{"AmountContent":200.00,
   "AmountCurrencyIdentifier":"CAD"}],
  "Item":[{
   "Description":[{"TextContent":"Axel"}]
  }]
 }]
}}

6.4. UBL-TransportationStatus-2.1-Example.json

{"Order":
 {
 "_D":"urn:oasis:names:specification:ubl:schema:xsd:Order-2",
 "_S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "_B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "UBLVersionID":[{"IdentifierContent":"2.1"}],
 "CustomizationID":[{"IdentifierContent":"urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0"}],
 "ProfileID":[{"IdentifierContent":"urn:www.cenbii.eu:profile:BII01:ver1.0",
  "IdentificationSchemeAgencyIdentifier":"BII",
  "IdentificationSchemeIdentifier":"Profile"}],
 "ID":[{"IdentifierContent":"34"}],
 "IssueDate":[{"DateTimeContent":"2010-01-20"}],
 "IssueTime":[{"DateTimeContent":"12:30:00"}],
 "Note":[{"TextContent":"Information text for the whole order"}],
 "DocumentCurrencyCode":[{"CodeContent":"SEK"}],
 "AccountingCostCode":[{"CodeContent":"Project123"}],
 "ValidityPeriod":[{
  "EndDate":[{"DateTimeContent":"2010-01-31"}]
 }],
 "QuotationDocumentReference":[{
  "ID":[{"IdentifierContent":"QuoteID123"}]
 }],
 "OrderDocumentReference":[{
  "ID":[{"IdentifierContent":"RjectedOrderID123"}]
 }],
 "OriginatorDocumentReference":[{
  "ID":[{"IdentifierContent":"MAFO"}]
 }],
 "AdditionalDocumentReference":[{
  "ID":[{"IdentifierContent":"Doc1"}],
  "DocumentType":[{"TextContent":"Timesheet"}],
  "Attachment":[{
   "ExternalReference":[{
    "URI":[{"IdentifierContent":"http://www.suppliersite.eu/sheet001.html"}]
   }]
  }]
 },{
  "ID":[{"IdentifierContent":"Doc2"}],
  "DocumentType":[{"TextContent":"Drawing"}],
  "Attachment":[{
   "EmbeddedDocumentBinaryObject":[{"BinaryObjectContent":"UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi",
    "BinaryObjectMimeCode":"application/pdf"}]
  }]
 }],
 "Contract":[{
  "ID":[{"IdentifierContent":"34322"}],
  "ContractType":[{"TextContent":"FrameworkAgreementID123"}]
 }],
 "BuyerCustomerParty":[{
  "Party":[{
   "EndpointID":[{"IdentifierContent":"7300072311115",
    "IdentificationSchemeAgencyIdentifier":"9",
    "IdentificationSchemeIdentifier":"GLN"}],
   "PartyIdentification":[{
    "ID":[{"IdentifierContent":"7300070011115",
     "IdentificationSchemeAgencyIdentifier":"9",
     "IdentificationSchemeIdentifier":"GLN"}]
   },{
    "ID":[{"IdentifierContent":"PartyID123"}]
   }],
   "PartyName":[{
    "Name":[{"TextContent":"Johnssons byggvaror"}]
   }],
   "PostalAddress":[{
    "ID":[{"IdentifierContent":"1234567890123",
     "IdentificationSchemeAgencyIdentifier":"9",
     "IdentificationSchemeIdentifier":"GLN"}],
    "Postbox":[{"TextContent":"PoBox123"}],
    "StreetName":[{"TextContent":"Rådhusgatan"}],
    "AdditionalStreetName":[{"TextContent":"2nd floor"}],
    "BuildingNumber":[{"TextContent":"5"}],
    "Department":[{"TextContent":"Purchasing department"}],
    "CityName":[{"TextContent":"Stockholm"}],
    "PostalZone":[{"TextContent":"11000"}],
    "CountrySubentity":[{"TextContent":"RegionX"}],
    "Country":[{
     "IdentificationCode":[{"CodeContent":"SE"}]
    }]
   }],
   "PartyTaxScheme":[{
    "RegistrationName":[{"TextContent":"Herra Johnssons byggvaror AS"}],
    "CompanyID":[{"IdentifierContent":"SE1234567801"}],
    "RegistrationAddress":[{
     "CityName":[{"TextContent":"Stockholm"}],
     "Country":[{
      "IdentificationCode":[{"CodeContent":"SE"}]
     }]
    }],
    "TaxScheme":[{
     "ID":[{"IdentifierContent":"VAT",
      "IdentificationSchemeIdentifier":"UN/ECE 5153",
      "IdentificationSchemeAgencyIdentifier":"6"}]
    }]
   }],
   "PartyLegalEntity":[{
    "RegistrationName":[{"TextContent":"Johnssons Byggvaror AB"}],
    "CompanyID":[{"IdentifierContent":"5532331183",
     "IdentificationSchemeIdentifier":"SE:ORGNR"}],
    "RegistrationAddress":[{
     "CityName":[{"TextContent":"Stockholm"}],
     "CountrySubentity":[{"TextContent":"RegionX"}],
     "Country":[{
      "IdentificationCode":[{"CodeContent":"SE"}]
     }]
    }]
   }],
   "Contact":[{
    "Telephone":[{"TextContent":"123456"}],
    "Telefax":[{"TextContent":"123456"}],
    "ElectronicMail":[{"TextContent":"pelle@johnsson.se"}]
   }],
   "Person":[{
    "FirstName":[{"TextContent":"Pelle"}],
    "FamilyName":[{"TextContent":"Svensson"}],
    "MiddleName":[{"TextContent":"X"}],
    "JobTitle":[{"TextContent":"Boss"}]
   }]
  }],
  "DeliveryContact":[{
   "Name":[{"TextContent":"Eva Johnsson"}],
   "Telephone":[{"TextContent":"1234356"}],
   "Telefax":[{"TextContent":"123455"}],
   "ElectronicMail":[{"TextContent":"eva@johnsson.se"}]
  }]
 }],
 "SellerSupplierParty":[{
  "Party":[{
   "EndpointID":[{"IdentifierContent":"7302347231111",
    "IdentificationSchemeAgencyIdentifier":"9",
    "IdentificationSchemeIdentifier":"GLN"}],
   "PartyIdentification":[{
    "ID":[{"IdentifierContent":"SellerPartyID123"}]
   }],
   "PartyName":[{
    "Name":[{"TextContent":"Moderna Produkter AB"}]
   }],
   "PostalAddress":[{
    "ID":[{"IdentifierContent":"0987654321123",
     "IdentificationSchemeAgencyIdentifier":"9",
     "IdentificationSchemeIdentifier":"GLN"}],
    "Postbox":[{"TextContent":"321"}],
    "StreetName":[{"TextContent":"Kungsgatan"}],
    "AdditionalStreetName":[{"TextContent":"suite12"}],
    "BuildingNumber":[{"TextContent":"22"}],
    "Department":[{"TextContent":"Sales department"}],
    "CityName":[{"TextContent":"Stockholm"}],
    "PostalZone":[{"TextContent":"11000"}],
    "CountrySubentity":[{"TextContent":"RegionX"}],
    "Country":[{
     "IdentificationCode":[{"CodeContent":"SE"}]
    }]
   }],
   "PartyLegalEntity":[{
    "RegistrationName":[{"TextContent":"Moderna Produkter AB"}],
    "CompanyID":[{"IdentifierContent":"5532332283",
     "IdentificationSchemeIdentifier":"SE:ORGNR"}],
    "RegistrationAddress":[{
     "CityName":[{"TextContent":"Stockholm"}],
     "CountrySubentity":[{"TextContent":"RegionX"}],
     "Country":[{
      "IdentificationCode":[{"CodeContent":"SE"}]
     }]
    }]
   }],
   "Contact":[{
    "Telephone":[{"TextContent":"34557"}],
    "Telefax":[{"TextContent":"3456767"}],
    "ElectronicMail":[{"TextContent":"lars@moderna.se"}]
   }],
   "Person":[{
    "FirstName":[{"TextContent":"Lars"}],
    "FamilyName":[{"TextContent":"Petersen"}],
    "MiddleName":[{"TextContent":"M"}],
    "JobTitle":[{"TextContent":"Sales manager"}]
   }]
  }]
 }],
 "OriginatorCustomerParty":[{
  "Party":[{
   "PartyIdentification":[{
    "ID":[{"IdentifierContent":"0987678321123",
     "IdentificationSchemeAgencyIdentifier":"9",
     "IdentificationSchemeIdentifier":"GLN"}]
   }],
   "PartyName":[{
    "Name":[{"TextContent":"Moderna Produkter AB"}]
   }],
   "Contact":[{
    "Telephone":[{"TextContent":"346788"}],
    "Telefax":[{"TextContent":"8567443"}],
    "ElectronicMail":[{"TextContent":"sven@moderna.se"}]
   }],
   "Person":[{
    "FirstName":[{"TextContent":"Sven"}],
    "FamilyName":[{"TextContent":"Pereson"}],
    "MiddleName":[{"TextContent":"N"}],
    "JobTitle":[{"TextContent":"Stuffuser"}]
   }]
  }]
 }],
 "Delivery":[{
  "DeliveryLocation":[{
   "Address":[{
    "ID":[{"IdentifierContent":"1234567890123",
     "IdentificationSchemeAgencyIdentifier":"9",
     "IdentificationSchemeIdentifier":"GLN"}],
    "Postbox":[{"TextContent":"123"}],
    "StreetName":[{"TextContent":"Rådhusgatan"}],
    "AdditionalStreetName":[{"TextContent":"2nd floor"}],
    "BuildingNumber":[{"TextContent":"5"}],
    "Department":[{"TextContent":"Purchasing department"}],
    "CityName":[{"TextContent":"Stockholm"}],
    "PostalZone":[{"TextContent":"11000"}],
    "CountrySubentity":[{"TextContent":"RegionX"}],
    "Country":[{
     "IdentificationCode":[{"CodeContent":"SE"}]
    }]
   }]
  }],
  "RequestedDeliveryPeriod":[{
   "StartDate":[{"DateTimeContent":"2010-02-10"}],
   "EndDate":[{"DateTimeContent":"2010-02-25"}]
  }],
  "DeliveryParty":[{
   "PartyIdentification":[{
    "ID":[{"IdentifierContent":"67654328394567",
     "IdentificationSchemeAgencyIdentifier":"9",
     "IdentificationSchemeIdentifier":"GLN"}]
   }],
   "PartyName":[{
    "Name":[{"TextContent":"Swedish trucking"}]
   }],
   "Contact":[{
    "Name":[{"TextContent":"Per"}],
    "Telephone":[{"TextContent":"987098709"}],
    "Telefax":[{"TextContent":"34673435"}],
    "ElectronicMail":[{"TextContent":"bill@svetruck.se"}]
   }]
  }]
 }],
 "DeliveryTerms":[{
  "ID":[{"IdentifierContent":"FOT",
   "IdentificationSchemeAgencyIdentifier":"6",
   "IdentificationSchemeIdentifier":"IMCOTERM"}],
  "SpecialTerms":[{"TextContent":"CAD"}],
  "DeliveryLocation":[{
   "ID":[{"IdentifierContent":"STO"}]
  }]
 }],
 "AllowanceCharge":[{
  "ChargeIndicator":[{"IndicatorContent":true}],
  "AllowanceChargeReason":[{"TextContent":"Transport documents"}],
  "Amount":[{"AmountContent":100,
   "AmountCurrencyIdentifier":"SEK"}]
 },{
  "ChargeIndicator":[{"IndicatorContent":false}],
  "AllowanceChargeReason":[{"TextContent":"Total order value discount"}],
  "Amount":[{"AmountContent":100,
   "AmountCurrencyIdentifier":"SEK"}]
 }],
 "TaxTotal":[{
  "TaxAmount":[{"AmountContent":100,
   "AmountCurrencyIdentifier":"SEK"}]
 }],
 "AnticipatedMonetaryTotal":[{
  "LineExtensionAmount":[{"AmountContent":6225,
   "AmountCurrencyIdentifier":"SEK"}],
  "AllowanceTotalAmount":[{"AmountContent":100,
   "AmountCurrencyIdentifier":"SEK"}],
  "ChargeTotalAmount":[{"AmountContent":100,
   "AmountCurrencyIdentifier":"SEK"}],
  "PayableAmount":[{"AmountContent":6225,
   "AmountCurrencyIdentifier":"SEK"}]
 }],
 "OrderLine":[{
  "Note":[{"TextContent":"Freetext note on line 1"}],
  "LineItem":[{
   "ID":[{"IdentifierContent":"1"}],
   "Quantity":[{"QuantityContent":"120",
    "QuantityUnitCode":"LTR"}],
   "LineExtensionAmount":[{"AmountContent":6000,
    "AmountCurrencyIdentifier":"SEK"}],
   "TotalTaxAmount":[{"AmountContent":10,
    "AmountCurrencyIdentifier":"SEK"}],
   "PartialDeliveryIndicator":[{"IndicatorContent":false}],
   "AccountingCostCode":[{"CodeContent":"ProjectID123"}],
   "Delivery":[{
    "RequestedDeliveryPeriod":[{
     "StartDate":[{"DateTimeContent":"2010-02-10"}],
     "EndDate":[{"DateTimeContent":"2010-02-25"}]
    }]
   }],
   "OriginatorParty":[{
    "PartyIdentification":[{
     "ID":[{"IdentifierContent":"EmployeeXXX",
      "IdentificationSchemeAgencyIdentifier":"ZZZ",
      "IdentificationSchemeIdentifier":"ZZZ"}]
    }],
    "PartyName":[{
     "Name":[{"TextContent":"Josef K."}]
    }]
   }],
   "Price":[{
    "PriceAmount":[{"AmountContent":50,
     "AmountCurrencyIdentifier":"SEK"}],
    "BaseQuantity":[{"QuantityContent":"1",
     "QuantityUnitCode":"LTR"}]
   }],
   "Item":[{
    "Description":[{"TextContent":"Red paint"}],
    "Name":[{"TextContent":"Falu Rödfärg"}],
    "SellersItemIdentification":[{
     "ID":[{"IdentifierContent":"SItemNo001"}]
    }],
    "StandardItemIdentification":[{
     "ID":[{"IdentifierContent":"1234567890123",
      "IdentificationSchemeAgencyIdentifier":"6",
      "IdentificationSchemeIdentifier":"GTIN"}]
    }],
    "AdditionalItemProperty":[{
     "Name":[{"TextContent":"Paint type"}],
     "Value":[{"TextContent":"Acrylic"}]
    },{
     "Name":[{"TextContent":"Solvant"}],
     "Value":[{"TextContent":"Water"}]
    }]
   }]
  }]
 },{
  "Note":[{"TextContent":"Freetext note on line 2"}],
  "LineItem":[{
   "ID":[{"IdentifierContent":"2"}],
   "Quantity":[{"QuantityContent":"15",
    "QuantityUnitCode":"C62"}],
   "LineExtensionAmount":[{"AmountContent":225,
    "AmountCurrencyIdentifier":"SEK"}],
   "TotalTaxAmount":[{"AmountContent":10,
    "AmountCurrencyIdentifier":"SEK"}],
   "PartialDeliveryIndicator":[{"IndicatorContent":false}],
   "AccountingCostCode":[{"CodeContent":"ProjectID123"}],
   "Delivery":[{
    "RequestedDeliveryPeriod":[{
     "StartDate":[{"DateTimeContent":"2010-02-10"}],
     "EndDate":[{"DateTimeContent":"2010-02-25"}]
    }]
   }],
   "OriginatorParty":[{
    "PartyIdentification":[{
     "ID":[{"IdentifierContent":"EmployeeXXX",
      "IdentificationSchemeAgencyIdentifier":"ZZZ",
      "IdentificationSchemeIdentifier":"ZZZ"}]
    }],
    "PartyName":[{
     "Name":[{"TextContent":"Josef K."}]
    }]
   }],
   "Price":[{
    "PriceAmount":[{"AmountContent":15,
     "AmountCurrencyIdentifier":"SEK"}],
    "BaseQuantity":[{"QuantityContent":"1",
     "QuantityUnitCode":"C62"}]
   }],
   "Item":[{
    "Description":[{"TextContent":"Very good pencils for red paint."}],
    "Name":[{"TextContent":"Pensel 20 mm"}],
    "SellersItemIdentification":[{
     "ID":[{"IdentifierContent":"SItemNo011"}]
    }],
    "StandardItemIdentification":[{
     "ID":[{"IdentifierContent":"123452340123",
      "IdentificationSchemeAgencyIdentifier":"6",
      "IdentificationSchemeIdentifier":"GTIN"}]
    }],
    "AdditionalItemProperty":[{
     "Name":[{"TextContent":"Hair color"}],
     "Value":[{"TextContent":"Black"}]
    },{
     "Name":[{"TextContent":"Width"}],
     "Value":[{"TextContent":"20mm"}]
    }]
   }]
  }]
 }]
}}

7. Moving forward

Once an agreed-upon serialization of CCTS in JSON is accepted, the committee can move forward by incorporating a new chapter in the http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.0/Business-Document-NDR-v1.0.htmlOASIS Business Document Naming and Design Rules titled "JSON validation artefacts", after the existing chapter "XML validation artefacts", to specify how to create a http://json-schema.org JSON Schema expression of an OASIS Business document.

A new equivalent chapter of http://docs.oasis-open.org/ubl/UBL-NDR/v3.0/UBL-NDR-v3.0.html OASIS UBL Naming and Design Rules will also be required to specify, among other items, which core component data type supplementary components are required rather than optional.