[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: Namespace URI string implications
At 2006-06-10 11:18 +0100, Mark Leitch wrote: >I agree with Jon and Tim on this. The only 'blind' transaction I >think is valid is the open request for quotation where the Customer >issues an RFQ that any supplier can respond to. But that is not an >interchange, it's simple a posting to a portal which demands a >response in a particular format; thereafter, the formalised >interchange takes place. 'Blind interchange' is not a requirement. I agree it is not a requirement at the business level of companies blindly accepting invoices from out of the blue. But in my talk about blind interchange and the serendipity of UBL working, I'm talking at the technical level of applications that are accepting and rejecting instances. For UBL to be easily deployed, a working application implemented for a given subset for a given version of UBL with a given set of functionality described for the information in the known portions of the XML instance, an implementation needs to be blind to variants that may arrive *after the trading partners have agreed to do business*. My point is that, say, I cannot send an invoice to the government of Antarctica blindly and expect it to be processed, but if I have an agreement with the government of Antarctica to send them an invoice and I have a UBL compatible system that prepares the information satisfying the core UBL information requirements, then the *software* deployed by the government of Antarctica could be able (if their policies allow) to blindly accept my invoice without regard for the presence of my extensions or the absence of their extensions. If it becomes mandatory that two UBL partners *are obliged to change their software implementations* in order to exchange the core information found in the standardized UBL constructs, then we won't have blind interchange *at the application level*. I do realize that some users of UBL may have immutable business requirements for extension information and violation of those requirements will trigger the rejection of transactions ... but that's not what I'm trying to address. When two parties have agreed to interchange information, and those parties have different implementations of UBL installed, and their respective business rules provide for successful transactions on the minimum common UBL-standardized information items without absolute need for extension information items, *then* their applications will successfully fulfill the transaction while being blind to the presence of unknown extensions and the absence of known extensions. Without this, won't we be back to bespoke, customized e-commerce transactions necessitating message-level negotiation of content and losing the serendipity of being able to use just the standardized constructs of UBL? Perhaps I'm missing something while I'm focusing on the technical bits. . . . . . . . . . . . . . . . Ken -- Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 Also for XSL-FO/XSLT/XML training: Birmingham, UK 2006-07-04/13 Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04 Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06 World-wide corporate, govt. & user group UBL, XSL, & XML training. G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]