[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] UBL 2.3 UBL-CommonAgregateComponents-2.3.xsd
I wasn't worrying about frivolity, but was from a concern about whether the full ramifications of such an extension had been explored.
It is obvious that no-one even raised any legal questions as they are not referenced in the documents you provided URLs to.
My comments were made as a response to the draft document, and I thought that this was the point of this mailing list.
If you remark is intended to re-open discussion of this problem then I am happy to move it to the other list, but it would be nice to have a clearer definition of what should be where - I know I asked before but obviously it is not clear enough yet.
David
On Monday, 26 August 2019 15:45:59 BST G. Ken Holman wrote: > Thank you for this comment, David. > > We will prepare a formal response as required by OASIS process. > > In the meantime, I draw your attention to the minutes of our > face-to-face meeting in Australia, January 2018, where the topic of > extension points first was raised for UBL 2.3: > > https://lists.oasis-open.org/archives/ubl/201801/msg00000.html > > The action item was followed up on and test schemas were produced for > the community to try: > > https://issues.oasis-open.org/browse/UBL-174 > > Feedback was positive: > > https://lists.oasis-open.org/archives/ubl/201808/msg00018.html > > And this approach was approved in our face-to-face meeting in the > Netherlands: > > <https://lists.oasis-open.org/archives/ubl/201810/msg00002.html>https://list > s.oasis-open.org/archives/ubl/201810/msg00002.html > > > Accordingly, the OASIS Business Document Naming and Design Rules > (BDNDR) have been updated pending feedback from the public review of UBL: > > <https://www.oasis-open.org/committees/document.php?document_id=64224>https: > //www.oasis-open.org/committees/document.php?document_id=64224 > > > I mention this for the benefit of readers of your comment in light of > the time it will take for our response. This UBL Comment list is not > an appropriate forum for open discussion. We will prepare a formal > response to your emailed comment at a future date. I won't take the > time today to respond to the individual points that you raise. My > objective today is to inform you that the change was not made > frivolously, but in response to identified user input. > > You may wish to bring the topic up for open discussion in UBL-Dev > where there may be feedback from others. > > . . . . . . . Ken > > At 2019-08-22 10:58 +0000, David Goodenough wrote: > >Looking further through the XSD files I see that ext:UBLExtensions > >has been added all over the place in the cac: definitions. > > > > > > > >I have to say I think this is a bad move. > > > > > > > >This comes back to the argument that I have raised before. Are you > >producing a Private Business Language Framework, or a Universal > >Business Language. > > > > > > > >If it is the former, then ext:UBLExtensions makes sense, it corrals > >the extensions into defined place, and gives the extension a name > >which makes policing name spaces much easier. For businesses who > >want to send data built with a private pre-agreed "version" of UBL > >this makes a lot of sense. > > > > > > > >However if UBL is to be genuinely universal it creates some real > >problems. These documents are legal documents, defining the > >interaction between businesses, and ext:UBLExtensions really have no > >place here at all. A generic client will have to ignore them and > >thus the receiver of the documents will be neither see nor be able > >to respond to the data encoded in these extensions - unless you are > >expecting a non-technical business person to read and write their > >own XML streams? And even if they can read them as XML, will then > >understand them? If they have been defined by some large company > >(and it will typically be large companies that do this) and they are > >simple presented as a fait-acompli (sorry if that is miss-spelt) > >what are they to do. > > > > > > > >If they are simply ignored by generic code, then we have to recall > >once again that these are legal documents. This is the equivalent of > >small print printed in such a small font that you can not read it, > >or worse written in invisible ink that only those in the know (and > >with the right reagent) can find and read. Fortunately at least in > >the UK this kind of clause will be thrown out as an "Unfair contract > >clause" by a reasonable judge, but should it really be necessary to > >go to court? > > > > > > > >What is worse is that you say that these extensions are "sometimes > >needed to satisfy legal requirements". How can it be right to have > >something that is not defined and therefore unreadable to users of > >generic code which is legally required? This section should really > >read something like:- > > > > > > > >"Nothing of legal significance should ever be encoded in a > >ext:UBLExtension unless that extension is part of the UBL standard > >or is the subject of a non-UBL private agreement between the two > >parties which includes the provision of software capable of > >interpreting and responding to any such data and a formally written > >specification of the extension. Further it should be assumed that > >without such a prior agreement the recipient will be unable to view > >or respond to any such extension" > > > > > > > >I am also not sure quite how I would encode in the > >DigitalCapabilities and DigitalAgreement documents the list of > >extensions that we have both agreed to accept. If there is no such > >mechanism then one is urgently needed. The generic code could then > >simply enforce an empty list of extensions. > > > > > > > >In the early days, UBL was functionally incomplete, and so > >extensions were necessary, but now that functional completeness is > >for most cases here they really should be deprecated. This will also > >highlight any areas that need improvement so that they are publicly > >and properly defined. > > > > > > > >Even as process extensions, so nothing of legal importance, this > >mechanism is of no real use if the recipient can not read or respond to > >them. > > > > > > > >The one exception to this is standardized extensions, such as the > >Digital Signature extension. While it would be better to have is as > >part of the regular datastream, the fact that is is defined in the > >standards document removes it from this discussion. > > > > > > > >David > > > > > > > >On Wednesday, 21 August 2019 15:50:40 BST David Goodenough wrote: > > > >In the definition of CustomsDeclaration starting at line 11146 there > >is a field (ext:UBLExtensions at line 11159) which does not appear > >in the .html files. Normally this would only be in a top level > >document rather than as here in a sub-component. > > > > > > > >Is this intended? > > > > > > > >David > > -- > 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]