Committee work on the use of JSON for UBL information interchange

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Fellow UBL Dev members,

Some of the UBL TC members have been working on describing a 
JSON-based document interchange format for UBL documents:

    https://www.oasis-open.org/committees/document.php?document_id=59528

Note in the caveats and assumptions in section 2 that this format is 
fully JSON ECMA-404 conformant but is not meant for use with any 
given tool, nor meant for use with any given API.  In fact, already 
it is known that the proposed format will not work with some 
JSON-based database tools.

The project is only to address exchanging a complete JSON instance 
that is backwards-compatible to future JSON instances that evolve as 
the UBL model evolves.  The result is admittedly esoteric compared to 
what is normally used in, say, an API based on JSON.

When it comes to JSON APIs, there are many vendor interpretations of 
how JSON should be used to represent business information, and there 
are many applications out there with their tailored implementations 
of JSON for particular purposes, for example, for big data.  The 
committee cannot choose any one in favour of others, nor is any one 
particularly better than the others in the general case.

The proposal has been successfully tested with JavaScript and Python 
programs that can ingest the document exchange format and produce 
whatever bespoke JSON might be needed for any particular vendor tool 
or project application.

The format can be losslessly transliterated with conformant UBL XML 
in a mechanical fashion without any semantic interpretation of any of 
the items.

These features satisfy the objective that some people have of "I 
don't want to use XML", while satisfying document engineering 
objectives of backwards-compatibility and semantic-free mechanical 
transliteration.

Seasoned JSON programmers can all hate it equally and still achieve 
lossless information interchange with each other using it.  A benefit 
could be argued that as a third-party definition, each party can hide 
their tailored and proprietary JSON approaches from the other party.

The format was not derived directly from UBL XML and is not a general 
purpose XML representation in JSON.  For those familiar with 
UN/CEFACT Core Components Technical Specification (CCTS) 2.01, this 
JSON format is created based on BIE concepts.  Accordingly, it will 
be proposed as a new JSON chapter in the OASIS Business Document 
Naming and Design Rules that are based on CCTS 2.01.

Comments from the community are welcome and are formally submitted 
through the Public Comment List:

  https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ubl

I hope you find this interesting.

. . . . . . . . . Ken

--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/u/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |