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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Developing open business information exchange documents

At 2017-02-23 15:01 +0100, u123724 wrote:
Thanks for this interesting read.
I appreciate the opportunity to discuss it. I'm proud of the work of our committee.

As I understand, CTS (not 100% sure about terminology here) models a
component model using UML, and then defines bindings to XML, JSON, EDI
Not quite, no. CCTS models a component model. Full stop. That model describes structures of aggregates (called ABIEs for Aggregate Business Information Entities). Each ABIE includes a set of branch components (called ASBIEs for Association Business Information Entities, each one defined by an ABIE) and leaf atomic components (called BBIEs for Basic Business Information Entities). Each leaf is described by one of 20 available Core Component Types (CCT). Each CCT has defined metadata.

CCTS itself ends right there: a hierarchical structure of business information entities as the semantic model of the information in the document being transmitted.

CCTS has nothing to do with UML, but some people find the UML graphical representation of this hierarchical structure convenient to read, and so the UBL committee published a UML alternative representation to the normative CCTS here:


CCTS says nothing about syntax. About 15 years ago the UBL committee created the concept of "Naming and Design Rules (NDR)", and since then a number of different groups have latched on to this concept of synthesizing syntactic constraints from a model. NEIM has NDRs. CCTS created their own NDRs. The UBL TC genericized its view of naming and design rules and the most recent version is out for public review with the addition of JSON schema synthesis rules:


We also published the UBL-specific application of these generic rules:


Accordingly, we have recently published the JSON schemas for UBL 2.1 for public review as an alternative syntax to the normative XSD here:


So ... the model is separate from the syntax. CCTS is standalone as a modeling tool. A user community chooses which NDRs to use to go from the model to the syntax. We believe our OASIS Business Document Naming and Design Rules (BDNDR) addresses real-world deployment issues better than do other NDRs. A user community then chooses which sytaxes they wish to make normative.

I've depicted the relationship of NDRs here in the BDNDR:


The spec document
goes right into an example where postal addresses are being modeled.
(noting that in the CCTS document that is but an example of method, not a prescription for an address model)

But having been involved in a project for modeling international
postal/logistical addresses, I found this to be an area where a
component model is impractical to use.

That's because postal addresses, as written on an envelope, carry a
huge legacy of special notations, concepts and nuances that can only
be conveyed in its conventionally written text form (postal addressing
also contains the problem of naming persons, which in itself is a
culturally diverse topic). In my project, I modeled addresses using
XML/XSD based on terms and concepts of UPU S42 (international postal
union standard, also an ISO affiliate organization). In particular, I
modeled it such that an address (in one of the supported formats)
could be stored/represented as tagged semistructured text, where the
line-oriented address (as would appear on a postal piece) was
optionally tagged with elements such as "postcode", "given name", etc.
Very true! And so the UBL model for the address includes a "catch all" unstructured address line, though unlike your approach it does not support mixed content, it is totally unstructured (not semi-structured). Here is UBL 2.1's CCTS model for a postal address (the address line is at the end):


When a user community deploys UBL, it decides *which* of the UBL items the community wishes to use for an address. UBL doesn't tell user communities what to do, it just makes semantic items available to the user community to choose from. With each new revision of UBL we solicit input from user communities to add to the UBL model the semantics they need they cannot already find. In a deployment users decide the UBL subset they agree upon. Here is an example of a deployment from Denmark:


In any other CCTS project, the user community can model the address any way they wish, provided it is element content.

I'm writing this because, even though we recently agreed here that XML
isn't designed as a data model format (or didn't we?), I've found
XML/markup (semistructured data) to be a proper representation format
for addresses specifically.
Personally, I'm growing to accept that an XML schema expressed entirely of element content and no mixed content doesn't have benefits over a JSON schema. CCTS defines only element content and no mixed content, and so I saw the opportunity to expand the NDRs to be able to synthesize JSON schemas from CCTS.

The proposed approach out for public review is specifically tuned for backward-compatibility in future revisions of the CCTS model ... for example, cardinality is on every information item and I've implemented cardinality using JSON arrays. That way if the user community increases the upper bound of cardinality in a future version of their specification, their legacy JSON instances will still validate even if their original cardinality was "1" because items of cardinality "1" are implemented with 1-sized arrays indexed with "[0]". This may appear wasteful on first blush, but the orthogonality on all items (including the document element) is intended to make simplify implementations. It is the committee's intention that JSON users will ingest our JSON document interchange format and create their customized big-data representations or database schemas tuned to their applications' requirements.

Again, the committee is only dictating information interchange between parties, not what the parties *do* with the information once ingested. That has a different mindset than application development. The choice of syntax becomes only a choice of how to ingest the content from a trading partner.

The UBL committee hasn't (yet?) decided to make the JSON serialization normative, but other committees using the NDR may wish to do so. It is the syntax du jour and element-only CCTS content works just fine with it. And I've written XSLT to transliterate UBL XML to UBL JSON losslessly, so there are no benefits of one over the other. It is what the *community of users* wants to choose. The UBL committee was struck in 2001 with the goal of creating normative XML constraints and so JSON wasn't in the picture at the time.

Maybe Roger wants to add this problem (which favours SGML/XML over
other approaches for one) to his ongoing data modeling effort. More
generally, I think there's a place for document-oriented
representation of eg. business transactions; namely, when you receive
and send eg. orders as *documents* and want to store these as-is (for
digitial signing, compliance, or other reasons);
I've come to believe the domain doesn't matter. As I've said above, it has come down for me to be a choice between all element-content or some mixed-content. All element-content can be either XML or JSON, any mixed-content dictates XML.

in this model, you
establish a business operational view (to use a term from UBL) by
extracting atomic values from documents.
The Business Operational View (BOV) is a term from the ISO/IEC 14662 Open-edi Reference Model, neither from UBL nor CCTS. It is the *semantic* view of electronic business. The Functional Services View (FSV) is the *implementation* view of electronic business. The committee overseeing Open-edi projects is ISO/IEC JTC 1/SC 32/WG 1 e-Business (which I volunteer on for Canada), and I am the editor of ISO/IEC 15944-20 that illustrates linking the BOV to the FSV.

The BOV establishes the existence of a semantic atomic value and its business component type in a document model, the FSV implements that as syntax. And I didn't just say "type" there because the core component types are business types, not XSD nor JSON types. For example, the "Amount" business type is a combination of a mandatory numeric value, a mandatory currency identifier and an optional currency code list version value. There is an XSD complex type and a set of JSON object properties defined accordingly.

Most of the members of the UBL committee are semantic business modelers who work only with the CCTS model and they never work directly with XML nor JSON. I'm the only one who has to look at the angle brackets and brace brackets.

I hope this has been helpful for all readers. Please let me know if there are any other questions.

. . . . . . . . . . . Ken

On Wed, Feb 22, 2017 at 3:43 AM, G. Ken Holman
<gkholman@cranesoftwrights.com> wrote:
> Not all XML-ers enjoy committee work. Imagine!
> It happens that I do, and I have had the privilege to volunteer in a number
> of standardization committees over the years related to SGML and XML
> projects of different kinds, from markup technology committees to markup
> user committees.
> A business document interchange specification governs the structure and
> expression of information to be exchanged between members of an industry or
> economic sector. I have come to believe that the burden of developing such
> a specification is on the users and not on the technical people supporting
> them. Accordingly, these user groups need processes, techniques and tools
> to enable subject matter experts to lead the development of open
> standardized work products.
> I've written an essay on how the Organization for the Advancement of
> Structured Information Standards (OASIS) technical committee process
> supports a group of members from an industry or economic sector in creating
> business exchange document specifications. The essay is an adaptation of a
> response I wrote last year for an RFP for the development of such an open
> document standard in XSD for XML. I ended up no-bidding the contract
> because the constraints were not loose enough to accommodate my proposal.
> But my proposal should be of interest to those just embarking on a project
> to develop exchange specifications without pre-conceived constraints.
> I illustrate my points using my experience with the OASIS Universal Business
> Language Technical Committee that produced the OASIS UBL 2.1 Standard that
> was subsequently ratified globally as ISO/IEC 19845:2015. The two normative
> components of the specification are the semantics of the information items
> and the XSD schemas for XML syntax. Non-normative deliverables include UML
> models, ASN.1 schemas and JSON schemas.
> Those not interested in committee work will find this essay an excellent
> treatment for insomnia. But for those of us XML-ers who are approached by
> their management or clients regarding the "big picture" of developing
> document exchange specifications, maybe even with the goal of developing an
> ISO standard for such, I hope you find this interesting:
> https://www.linkedin.com/pulse/developing-open-business-information-exchange-documents-ken-holman
> . . . . . . . . Ken
> cc: XML Dev, XML-L, W3C XML Schema, UBL Dev

UBL introduction lecture - Exchange Summit - Orlando, FL - 2017-04-24 |
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS