OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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