[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Developing open business information exchange documents

  • From: u123724 <u123724@gmail.com>
  • To: "G. Ken Holman" <gkholman@cranesoftwrights.com>
  • Date: Thu, 23 Feb 2017 17:57:51 +0100

Re:  Developing open business information exchange documents
Thanks again for your comprehensive and most informative response.

> 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.

That makes sense; however, while I don't know the situation with UBL
specifically, in said address consolidation project I came across
established postal address representation schemes for XML making heavy
use of their own ad-hoc "meta" systems in XML (eg. as in <field
role="this">that</field>) which I always found to have a smell.

> 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.

That is along the lines as discussed last week here. My point was to
get an opinion of whether it's accepted that there is

- intrinsic semantic information in the formatting/presentation of
text getting lost in component representation ("fielded addresses")
unless going to extremes in preserving sequence of eg. lines and
individual tokens or vertical alignment information

- a benefit in having a document as a palpable/material manifest for a
business transaction in the digital age

These points don't focus so much on formal, grammatical, or logical
arguments as they accept a cultural "humanist/antropocentric" view
about technology and information modeling.

Also, a theoretical point could be made that, since almost any
business process requires the identification of parties/persons
(natural or otherwise), and hence address data, a data serialization
format should be equipped with semistructured data modelling

On Thu, Feb 23, 2017 at 4:48 PM, G. Ken Holman
<gkholman@cranesoftwrights.com> wrote:
> 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
>> etc.
> 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:
>   http://docs.oasis-open.org/ubl/UBL-2.1-UML/v1.0/UBL-2.1-UML-v1.0.html
> 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:
> http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/Business-Document-NDR-v1.1.html
> We also published the UBL-specific application of these generic rules:
>   http://docs.oasis-open.org/ubl/UBL-NDR/v3.0/UBL-NDR-v3.0.html
> Accordingly, we have recently published the JSON schemas for UBL 2.1 for
> public review as an alternative syntax to the normative XSD here:
>   http://docs.oasis-open.org/ubl/UBL-2.1-JSON/v1.0/UBL-2.1-JSON-v1.0.html
> 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:
> http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/Business-Document-NDR-v1.1.html#F-NAMING-AND-DESIGN-RULES-IN-AN-OPEN-EDI-APPLICATION
>> The spec document
>> (http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS_V2-01_Final.pdf)
>> 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):
> http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Address.Details
> 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:
>   http://oioubl.info/classes/en/index.html
> 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]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.