[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: Thoughts on Ken's UBL Customization document -gkholman-ubl-modeling-0.4
I could certainly, myself, imagine this happening in real life situations, even for small businesses. Agreeing to use a known subset may allow much to be done in advance and get folk trading without all this initial preparation (like instant coffee). * But * it probably won't, I think, prevent the need for what you have stated here from happening too in the medium term. Very interesting :-) All the best with this week's discussions Steve >>> "G. Ken Holman" <gkholman@CraneSoftwrights.com> 14/08/06 00:33:02 >>> At 2006-08-13 13:31 -0700, jon.bosak@sun.com wrote: >[gkholman@CraneSoftwrights.com:] > >| My goal is to find a way such that the software >| is not a barrier to doing business ... that a >| minimum mode of operation of the software still >| allows sufficient information to be exchanged >| such that the recipient can deal with the core >| information without the sender having to take the >| time to re-configure their system. > >I think what you're saying is that the necessary stuff that's >*not* conveyed by the core will be handled out of band for the >nonce. Indeed ... and in some one-off or temporary situations only the recipient will really know what more is required on top of the mandatory items. Until the sender has changed their software to meet the receiver's requirements, they can still effect transactions with the minimum data and the receiver can supplement that with whatever is needed. I'm assuming this is in the receiver's interest: that *not* receiving any information from the sender is worse than receiving the raw bits and going from there. >You're not expecting the data absolutely required by the >UBL schema to be sufficient for the whole transaction; rather, >you're saying that acceptance of the core instance data reduces >that part that has to be managed out of band to something that >real people can handle through, say, an email exchange or a phone >call followed by a little hand editing in order to effect one >particular transaction. Right ... it might be some legal filing, some tax calculations that only the receiver knows and the sender hasn't built into their system yet ... whatever. >Perhaps this happens only once, in which >case the dialogue, properly recorded, can serve as a framework for >defining what has to be added to the process to include this new >partner. Or perhaps it happens once a week, not often enough to >change the software but often enough to become a familiar chore >that's worth the trouble given the amount of the transaction or >the importance of the customer. And doing the business is sufficiently worthwhile to both parties that they can live with the temporary or limited situation and still use their electronic frameworks to convey the raw information. >While the core data is insufficient to complete the transaction, >the underlying semantic notion of "invoice" or "order" has been >unambiguously established: both partners now know what they're >trying to accomplish, and the delta establishes the neural pathway >for a new trading relationship. Is that about right? Perfect. Which was the reason for me publishing what the schemas already say about the minimum mandatory elements: are these sufficient to convey for each document type the underlying semantic notion and raw information. >The core data exchange establishes the "business link layer," so >to speak. Well said! >I have to agree that this mode of operation should enormously >expand the range of trading partners that can be engaged on a new >or occasional basis. And it is voluntary, or optional, on the part of the receiver: they could surely enforce the business rules if they want, but having the minimal mode would give them the ability to convey the raw information. >Then "UBL Open" becomes a business slogan and a badge, doesn't it? Yes, I was kind of using it in that fashion, thinking that it would be catchy and would convey that such a UBL user is this open, when desired, for at least conveying the raw information. Thanks, Jon! . . . . . . . . . . . . Ken -- UBL/XML/XSLT/XSL-FO training: Vårø, 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]