OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Committee work on the use of JSON for UBL information interchange

Fellow UBL Dev members,

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


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:


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 |

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]