[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: Namespace URI string implications
no Ken you are correct, we were talking about different layers of the inteoperability stack. sorry to confuse the issue. there is a requirement for applications to be able to verify a document's compliance with UBL, regardless of their specific customizations and implementation requirements (i.e. to recognize "UBL compliant applications") G. Ken Holman wrote: > 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 web: http://www.portcomm.com.au/tmcgrath
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]