[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 15:01:07 +0100

Thanks for this interesting read.

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

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.

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); in this model, you
establish a business operational view (to use a term from UBL) by
extracting atomic values from documents.

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 |
> Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
> Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
> Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/x/ |
> G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com |
> Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
> Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

• Follow-Ups:
  • Re: Developing open business information exchange documents
    • From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>

• References:
  • Developing open business information exchange documents
    • From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>