[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Maybe I have misunderstood it...
And, anyway, we also have a chartered obligation to respond formally to all public comments.
Indeed the UBL committee made the decision early on in the process of UBL 2.0 (I can remember the face-to-face in Ottawa in August 2005 where we came to this conclusion) to abandon the UN/CEFACT naming and design rules' approach to baked-in code lists. We voted as a committee to (eventually) pull out of UBL all schema enumerations and to leave it to communities of users to specify (worry about) all coded values, both static and dynamic. This has been codified since in our formal OASIS Business Document Naming and Design Rules, now at version 1.1:
http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/Business-Document-NDR-v1.1.html
And we have believe firmly this has made UBL truly universal. The instances of UBL created across Europe, in Peru, in Colombia, and in all other user communities, all validate using the off-the-shelf XSD schemas published by the committee. As a third party (perhaps I'm an auditor) I can download the schemas for myself and run any putative UBL instance against those schemas to know that the structure is correct.
Of course interoperability is leveraged heavily on coded values, as it always has and as it should. But interoperability is different in every community and the same within any given community.
In Denmark, coded value interoperability is defined here: http://oioubl.infoFor the European Commission, coded value interoperability is defined by CEN/BII and now TC434 and TC440.
In Peru, coded value interoperability is defined here:<http://cpe.sunat.gob.pe/factura-desde-los-sistemas-del-contribuyente>http://cpe.sunat.gob.pe/factura-desde-los-sistemas-del-contribuyente
Every community of users has an obligation to document interoperability with UBL.
We do not see this an "admission of failure" in any way. We are proud of how UBL has become the foundation of interoperability in so many projects around the world. We see UBL as having successfully become the "HTML of e-commerce": a single commonly-agreed upon structure that can be used by anyone in any way to contribute to solve a myriad of e-commerce solutions by already solving the vocabulary, just not constraining people to how the vocabulary is used. Consider how the world has used the grammatical structures of HTML elements in uncounted different ways ... the same is happening with UBL. Even the UBL swim-lane diagrams are illustrative and not normative ... they exist only to help infer the role of the documents described by their semantics.
From our UBL committee charter: https://www.oasis-open.org/committees/ubl/charter.php "The primary deliverable of the UBL TC is a coordinated set of XML grammatical components that will allow trading partners to unambiguously identify the business documents to be exchanged in a particular business context."Using the schema and the documented semantics of the business objects as structures, our users identify the business documents and their content found in a given XML document.
Then, only communities of users can properly dictate what the values are to be in those objects and how those values are to be interpreted. Such is expressly outside the scope of our committee charter.
I hope this has helped to illuminate our perspective on this. . . . . . . Ken At 2017-09-28 16:00 +0100, David Goodenough wrote:
To bit a bit harsh/blunt, this could be interpreted as saying you are not trying to produce a universal standard, just a framework that small communities (of big companies) can use for their own purposes. Seriously if UBL is to become universal, and certainly the EU have indicated that they would like it to, such things have to be defined to that many implementations can inter-operate without having to find out first which flavor your trading partner has adopted. The existence of additional agreements in order to use UBL could be seen as an admission of failure. I can quite see that the Codes fall into at least three categories and that these need to be handled in different manners:- 1) Those derived from International lists, such as countries and currencies. This also applies to things like units of measure which are the subject of international standards. Deriving those from their external source is the only way to go and this seems to be done. 2) Common usage within an industry. For example in the cereal seed business they can be packed by weight or seed count. Seed counts are not much use in the milk business, nor are things like thousand grain weights. Likewise the airfreight and maritime logistics worlds have well developed codes. Either there need to be a super set of all which might be unwieldy, or they need to be clearly marked as to where they come from - which you do well. 3) Structural or protocol codes. These are the ones that are sadly lacking, and are absolutely vital for interoperability. There may need to be multiple level codes, so a standardized one and an explanatory one, but the standardized one is a basic requirement for a usable general standard. The Internet Email standards (or come to that the rest of the Internet) would not have been widely adopted if such items had been left open. And in fact the problem areas are exactly those that were loosely defined. This has given rise to such things as at least two confirmation of delivery implementations, and the lack of definition about the tie-up of the outer SMTP envelope and the inner message envelope is the reason why most of the spam emails get through. (getting off my high horse) David On Thursday, 28 September 2017 10:14:05 BST G. Ken Holman wrote: > Thank you, David, for this input. > > I have distilled your comments as follows and provided an initial > response in an attempt to give you a timely answer. This response > will be reviewed by the UBL Technical Committee for any additional comment. > > (1) - the representation of positive/negative responses > > It is intended that the <cac:DocumentResponse> ASBIE capture the > representation of the response: >> http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocumen> ts-2.1.html#Table_ApplicationResponse.DocumentResponse > > The structure of the ABIE is outlined here: >> http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocumen> ts-2.1.html#Table_DocumentResponse.Details > > ... in which one finds the response ASBIE to this ABIE: >> http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocumen> ts-2.1.html#Table_Response.Details > > ... in which one can place the response code as defined by the users > of the customization of UBL. > > The UN/CEFACT Core Component Type for codes defines optional > BBIE-level metadata in attributes that can be used to identify the > code list associated with the coded value. > > (2) - the lack of standardization of the use of any coded values in UBL > > The absence of any specification of particular code lists in the UBL > conformance clauses is intentional. The committee has imposed no > constraints of any kind on the values of codes (other than the > lexical constraint of being a normalized string, per the UN/CEFACT > Core Component Type). > > Accordingly, the conformance clauses state only conformance to schema> constraints and additional document constraints not expressed in the schema:> > http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#S-CONFORMANCE > > Understanding the important role of code lists, UBL 2.1 includes a > non-normative annex describing one possible method of a user > community imposing coded value constraints on top of the > conformance-related document structure constraints: >> http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#A-UBL-2.1-CODE-LISTS-> AND-TWO-PHASE-VALIDATION > > In support of this candidate method, and to demonstrate its use, the > committee has created genericode representations of popularly-used > code lists users may find helpful in their use of UBL. The > demonstration environment includes an XSLT stylesheet that > incorporates the provided selection of illustrative code lists. > > Early in the development process the UBL committee determined that > code lists are sufficiently varied and sufficiently fluid so as to be > applied differently in all contexts of use of UBL worldwide and over > time. Especially given how code lists can change from their > publisher, and can change in which codes are used perhaps on a daily > basis, baking in coded values into the UBL schemas would make the > schema expressions extremely fragile. > > Whereas, by divorcing coded values from the conformance schemas, one > can claim at all times schema structural conformance to the read-only > published specification with full backward compatibility to future > revisions of UBL. Our committee responsibility ends at the > schemas. And to be consistent, *all* coded values are external to > the schemas, even for concepts not likely to change (latitude and > longitude directions for an example of this). > > This puts the onus on the user community to define for their > particular community what the coded value constraints shall be and > how they are to be validated. > > . . . . . . . Ken > > At 2017-09-28 12:32 +0100, David Goodenough wrote: > >but the ApplicationResponse object strikes me as strangely disappointing. > > > > > >> >Looking at the flow diagrams, there are references to negative and positive> >> >responses, this is not explicitly represented in the ApplicationResponse or> > > >any of its sub-objects. > > > > > > > >There also does not seem to be a standard set of StatusReasonCodes or > > > >ResponseCodes. Surely there are a bunch of specific responses, many of > > > >which are shown in the flow diagrams, which could, or rather should be > > > >defined for interoperability. There might be supplimentary information > > > >which is implementation specific and might be used by humans to solve > > > >a problem, but the basic logic flow states should be defined in the > > > >standard. > > > > > > > >There is a DocumentStatusCode, but that is only used for transport > > > >related activities. > > > > > > > >Given that I am new to this lot, it might be that I have simply not found > > > >the code lists, but there is actually no reference to either > >StatusReasonCode > > > >or ResponseCode in the:- > > > > > > > >Universal Business Language Version 2.2 > > > >Committee Specification Draft 01 / > > > >Public Review Draft 01 > > > >21 December 2016 > > > > > > > >and no genericode definition for either that I can find, and no codes > > > >listed on the flow diagrams. > > > >David > > > >(Confused of Broadwell)
-- Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ | 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] | [List Home]