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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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