NDR Specification

We received more than sufficient yes votes to pass the NDR specification. We did receive two no votes (it appears there is a problem with the vote archive page as it indicates a total of 3 no votes but one had been withdrawn and only two remain). The OASIS processes states:

"If at the end of the voting period at least 15 percent of the voting membership has voted to approve the proposed standard, then if no votes have been cast to disapprove the proposed standard, it shall become an OASIS Standard immediately following the end of the voting period. However, if negative votes amounting to less than 15 percent of the voting membership have been cast, the TC will be notified of the negative votes, after which the TC shall have 30 days to take one of the following actions by resolution: (a) request OASIS TC Administration to approve the specification as submitted despite the negative votes; (b) withdraw the submission entirely; or (c) submit an amended specification, in which case the amended submission shall be considered as if it were a new submission, except that information regarding previous votes and any disposition of comments received in previous votes shall accompany the amended submission."

Our "no" votes and their justification are:

?BEA Systems votes no on UBL Naming and Design Rules v1.0 as an OASIS Standard. BEA commented during the public review that we believe that distributed extensibility and versioning is a key architectural component of distributed systems and UBL should allow for distributed extensibility [1]. The UBL TC responded to the effect that exchanging business documents where one side did not have the extension schema - what we have called distributed compatible extensibility - is not in business interests because both sides must understand any extensions for continued exchange. We believe that this requirement - that all parties in an exchange must simultaneously deploy new schemas and semantic understanding - is too onerous for business scenarios. There is a long history of compatible evolution of business documents that could be formalized and fostered by UBL. We are very concerned that this design will lead to very tightly coupled and brittle business systems. We are also concerned that this specification will act as an undesirable model for other specifications."

"SAP believes that the "Garden of Eden" approach used in UBL NDR, i.e. to use global element definitions only, is hard to implement and to maintain. The more flexible "Venetian Blind" approach, i.e. to allow local element definitions where appropriate, should be used instead."

These comments are virtually identical to those submitted by these two organizations during the first review period in October. We addressed both of these comments at our Face 2 Face Meeting in November. Both are opinions on how best to use XML and XSD - rather than technical arguments that invalidate the UBL NDR approach. I would like to make a motion that we recommend to OASIS TC Administration that the NDR become an OASIS standard forthwith and would ask Jon to initiate the most expeditious TC process available to seek consensus within the TC on my motion.

ubl message