[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
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]