Re: [xml-dev] Developing open business information exchange documents

[u123724 <u123724@gmail.com>]

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

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