[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
My preemptive response today was to address for the benefit of other readers any implication that we made this important change just for change sake, as we made the change in response to specific user requirements that I identified.
The legality of documents is interpreted by the user community defining how the documents are used. Should a user community choose to prohibit extensions beyond the document element, that would be up to the user community to dictate and enforce.
The UBL committee is not in a position to proclaim the UBL document structures to be legal in any sense. All we can dictate is the normative conformance clauses of schema validity and additional document constraints.
How UBL documents are interpreted is up to users, not to us. That was why I thought you bringing up the discussion in the user community UBL-Dev would be more appropriate to get community feedback regarding your question. You may choose to take any conclusions you arrive at to the UBL committee through another post to this UBL Comment list.
So you have used the lists appropriately to register your concerns ... we just cannot use this UBL comment list for a general discussion. I suggest you express your concerns to the UBL-Dev list as well to invite comment and discussion from others.
Better yet, you could consider membership in OASIS and direct participation in the committee work! That would short-circuit a lot of formality.
We look forward to your feedback to the official committee response to your comment when it is prepared after the end of the public review period.
. . . . . . Ken At 2019-08-26 20:58 +0000, David Goodenough wrote:
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]