[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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 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) | >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|