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) |
