[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Invitation to comment on Universal Business Language v2.3 from the UBL TC - ends February 15th
|
Hi David > In the Invoice definition, InvoiceLine is shown with a type of ASBIE, in the definition of InvoiceLine it is shown as an ABIE. Why the difference? ABIEs are reusable information items defined in the UBL common library. An invoice (as well as any other UBL document) consists of a number of information items. These can either be single information items (BBIEs) such as the invoice ID,
or blocks of information associated with ABIEs such as the InvoiceLine. The InvoiceLine ASBIE in the Invoice document is simply an association to the InvoiceLine ABIE in the common library. You can think of ABIEs as classes in programming, and of ASBIEs as
locally declared variables of a class. Hope that is helpful. You can also have a look at the definitions in chapter 9 of the UN/CEFACT Core Component Technical Specification:
http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS_V2-01_Final.pdf > Extensions means that UBL documents can not Legally binding business documents on the grounds that you can not assign legal significance to a part of a document that the recipient can not read Just because the content of an extension is not defined within UBL doesnât mean that it has been defined unilaterally by the sender and is unintelligible to the recipient. On the contrary, a successful
exchange of information (excluding those extensions that some implementers include for their internal software processing) would assume that it has been agreed upon by the sending and receiving parties, either bilaterally or within a community of users. > The point about making the extension definition a defined part of a document is that then a generic program can be used to decide whether this is an acceptable document You can also look at it the other way: the point of extensions is to make a document acceptable - even if subject to requirements that are not (yet) contemplated within UBL itself. > I have already proposed a possible way to define the acceptable extensions should be encoded. Yes (https://lists.oasis-open.org/archives/ubl-comment/201909/msg00000.html), which we reviewed and debated carefully within the TC before responding.
Again, while there may be different and better ways to do this, we do believe that the general functionality of conveying data model and content requirements (including the use of extensions) is covered by the Profile ID and Customization ID elements. Notwithstanding,
there is one more side to this, which is the discovery and conveying of capabilities in the message exchange process. This doesnât fall within the scope of UBL, but you can have a look at the work products from the OASIS ebXML Messaging Service and Business
Document Exchange TCs: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=bdxr Specifically the ebMS3 and SMP specifications may be of interest to you. > On the subject of the messages referenced in the response my objection, these do not seem to be messages to the only two UBL mailing lists that I am subscribed to I quoted the following three messages in our comment resolution log, all of which are on the UBL Comment list: https://lists.oasis-open.org/archives/ubl-comment/201908/msg00003.html https://lists.oasis-open.org/archives/ubl-comment/201908/msg00006.html https://lists.oasis-open.org/archives/ubl-comment/201909/msg00000.html > If I had a vote, which I appreciate I do not, I would vote against 2.3 just on the basis of the propagation of extensions. Well, you could!! OASIS membership is open to everyone and we would very much welcome your participation in the TC! :-) Best regards, Kenneth From: David Goodenough <david.goodenough@broadwellmanor.co.uk> Kenneth,
1) In the Invoice definition, InvoiceLine is shown with a type of ASBIE, in the definition of InvoiceLine it is shown as an ABIE. Why the difference?
I also do not understand how having bits of a document that a party can not read can be compatible with the paragraph at the top of page 11 of the PDF UBL manual. Extensions means
that UBL documents can not Legally binding business documents on the grounds that you can not assign legal significance to a part of a document that the recipient can not read. It is not just the possibility of misuse that bothers me, it is the entire concept.
2) The point about making the extension definition a defined part of a document is that then a generic program can be used to decide whether this is an acceptable document. I agree
that no functionality should be allowed that duplicates existing function, and this is a start, but the question that needs to be answered is "how does a user read a document with extensions he can not read, and how does a generic program notify the user (other
than showing them a bit of UBL XML which would be unacceptable) that there is something there that they can not read. Saying that people should define their own object domains keeps the extensions unique, but does nothing to make them readable.
I have already proposed a possible way to define the acceptable extensions should be encoded.
Frankly I believe that extensions other than standardised ones like the cryptographic one should be deprecated, and then removed in a future release. Extensions are an admission
of failure, and we should not be planning for failure.
On the subject of the messages referenced in the response my objection, these do not seem to be messages to the only two UBL mailing lists that I am subscribed to (ubl-comment and
ubl-development), both of which I have been reading for a while now. Which mailing lists are they on, and where do I sign up to them?
If I had a vote, which I appreciate I do not, I would vote against 2.3 just on the basis of the propagation of extensions.
David
On Tuesday, 4 February 2020 16:59:29 GMT Kenneth Bengtsson wrote:
Hi David
Thanks for your input. Let me try to clarify:
1) Previous UBL versions only allowed extensions at the document level, which is different from allowing extensions to
ABIE elements. Consider for example an invoice with several invoice lines. Previous UBL versions would only allow you to extend the invoice document itself, but not the invoice line ASBIE itself. The following is now possible with UBL 2.3:
Invoice document
- Invoice line 1
- - [Extension with information related to invoice line 1]
- Invoice line 2
- - [Extension with information related to invoice line 2]
There are no changes to this between the first public review and the current public review, except for the clarification in the specification (sections 3.5.1 and 3.5.2). The XML schemas themselves remain unchanged.
Personally I share your concern about possible âmisuseâ of extensions, and I do think it important to emphasize that the extensions are intended for adding information that cannot be expressed using existing UBL vocabulary (i.e. information and elements that
were not contemplated within UBL itself). Extensions are not intended for creating alternative ways of conveying information that already has its place in UBL. Weâve tried to clarify this with section 4.7.
2) I believe there is a difference between being âreliantâ on non-UBL documents and being able to make reference to non-UBL documents. Business documents frequently make reference to other documents, and some of those documents are defined elsewhere and fall
outside the scope of UBL (contracts and agreements, legal documents, technical drawings, project plans, photographic images, just to name a few). UBL provides mechanisms for making references to such documents, and your vision that agreements should be expressed
in a structured and standardized format is excellent. It is certainly what we are working for as well. Specifically for agreements about data model and content requirements (including extensions), UBL has the Profile ID and Customization ID, and 2.2 introduced
the Digital Agreement document type. Your suggestions for how these can be improved, as well as for any additional information items and document types we can add will be more than welcome!
Best regards,
Kenneth
From: David Goodenough <david.goodenough@broadwellmanor.co.uk>
Looking at this list I am royally confused.
1) The original 2.3 proposal that I reacted to was to add extensions to ALL compound UBL objects, but 3.5.2 has been changed to say only ABIE objects (i.e. root objects) can have extensions, which is what previous versions had. The discussion says that effectively
my objection was rejected, but the text says that UBL has reverted to pre-2.3 behaviour. While I don't like extensions at any level, the pre-2.3 extensions are already there and given the wish to remain backward compatible it would be difficult to remove them.
2) The point of my second object was that the agreement process for allowing extensions should have a digital representation that was part of the exchanged datastreams. Having it in separate unstructured documents, phone calls, post it notes or whatever really
misses the point. UBL should be self contained, and not reliant on non-UBL documents!
David
On Monday, 3 February 2020 19:02:00 GMT Paul Knight wrote:
Hi David,
I'm not at all involved in the technical work of UBL, so this may not be the specific item you are asking about, but I see that two issues you had raised are addressed as the first two entries in the "comment resolution log" prepared by the UBL TC after the
first public review. It appears that some changes were made based on your comments.
If you have not already seen that, it may be helpful.
By the way, thanks very much for your interest and comments.
This is cited from the announcement, at [2]:
[2] Previous public reviews:
Best regards,
Paul
On Mon, Feb 3, 2020 at 1:14 PM David Goodenough <david.goodenough@broadwellmanor.co.uk> wrote:
By the look of it the objection to universal extensions has been accepted, which if it is true is good news.
As a comment on the process that lead to that acceptance, it is strange that a formally raised (at least I think I raised it formally) matter such as this has never actually been responded to. No documentation seems to exist (at least that I have come across)
about the discussion that happened as a result of my observations. It is quite possible I am simply not looking in the right place - if so please can someone tell me where to look.
David
On Monday, 3 February 2020 16:10:31 GMT Paul Knight wrote:
Hi David and all,
While not a "list of changes", there is an accompanying "diff" file noted in the announcement, at footnote [3]. In case you missed that in the original announcement, I hope it is helpful.
[3] Red-lined version:
Best regards,
Paul
On Sat, Feb 1, 2020 at 1:44 PM David Goodenough <david.goodenough@broadwellmanor.co.uk> wrote:
Is there a list of changes since the first public review? A quick look did not reveal one, but I may have missed it.
David
On Friday, 31 January 2020 17:58:58 GMT Paul Knight wrote:
OASIS Members and other interested parties,
Paul Knight....Document
Process Analyst...mobile: +1 781-883-1783
OASIS - Advancing open standards for the information society
Paul Knight....Document
Process Analyst...mobile: +1 781-883-1783
OASIS - Advancing open standards for the information society
Paul Knight....Document
Process Analyst...mobile: +1 781-883-1783
OASIS - Advancing open standards for the information society
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]