A new syntax for smart contract representation of UBL semantics

[srowlison]

The proposal would see implementations in the programming language Solidity used in Ethereum Blockchain smart contracts representing UBL semantics. TAP, DCL and DCP would be referenced.

[onthebreeze]

Related to #42

Sounds like a good idea to provide that bridge between an Etherium smart contract world the broader B2B world!

Thinking about it a bit, we currently have SYN v1 spec (UBL XML semantics) and SYN v2 (UBL JSON semantics) specifications. It occurs to me that it's probably not right to consider these different syntax representations as "versions" of the SYNtax spec but rather as equal peers. So I'd be supportive of allowing a range of independent but interoperable syntax representations of common semantics like UBL. So id like to propose that

• we rename SYN v1 to SYN-XML
• we rename SYN v2 to SYN-JSON
• we add a third SYN-SOL to represent the solidity language (used by etherium) and this can be your spec as editor.

How does that work for you?

We've made some effort to make sure that we can do a lossless transform between XML and JSON representations (see http://testpoint.io/syn) and I think it's even more critical that a solidity representation can be losslesly transformed as it travels between the specific etherium walled garden and the "outside world" via an oracle service. So I think that would mean that you might want to consider working with us to update testpoint.io/syn so that we can verify SOL <-> (XMl and/ or JSON)?

[monkeypants]

+1 vote for a SYN-SOL syntax standard that maps EDI semantics to Solidity consistently

+1 vote for renaming SYN-* specs for their syntax target, and maintaining (mandating) lossless bidirectional transformation ability between them all.

Solidity is so similar to ECMAScript that this seems like it should be a fairly straightforward mapping exercise (fatal last words!) .

The differences between Solidity and ECMAScript don't seem like they would be a problem:

• static typing: harmless (it's a data mapping)
• complex member variables: JSON schema
• variadic return types: avoid putting apples and oranges together in the same list (or use duck-typing, etc)
• multiple inheritance: be careful

[srowlison]

Acknowledged

[gkholman]

Crane Softwrights Ltd. supports the proposed approach to develop an alternative lossless syntax representation of OASIS UBL using Solidity, with the added suggestion that such an approach be generalized to UN/CEFACT Core Component Technical Specification (CCTS) v2.01 as described by the OASIS Business Document Naming and Design Rules (BDNDR). Doing so will ensure the techniques developed for current UBL documents can similarly be applied to future UBL documents and non-UBL documents that also are developed based on CCTS using BDNDR. As UBL already includes a number of transportation-related documents, the techniques developed should open up support for a range of new far-reaching applications and should garner the attention of projects in other domains that are considering the same class of implementations.

Moreover, it is suggested that to promote interoperability with other communities of users the outside interfaces (e.g. import/export) to the Solidity implementation losslessly support the syntaxes described in the BDNDR (currently XML and a proposed use of JSON), prioritizing those syntaxes that are normative to UBL (currently XML).

[srowlison]

Thanks, I take it that this proposal is approved and it is now possible to commence the interface specification.

[onthebreeze]

yes that's good enough for supporters.

We will make the necessary changes (renaming our current SYN v1 / v2) and setup the framework to commence work on the spec.

Cool!