Re: [ubl] Re: Namespace URI string implications

[Tim McGrath <tmcgrath@portcomm.com.au>]

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