MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Re: Namespace URI string implications
From: "G. Ken Holman" <>
To: <>
Date: Sat, 10 Jun 2006 15:09:43 -0400
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:
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
