Re: Thoughts on Ken's UBL Customization document -gkholman-ubl-modeling-0.4

[jon.bosak@sun.com]

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

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?

The core data exchange establishes the "business link layer," so
to speak.

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.

Then "UBL Open" becomes a business slogan and a badge, doesn't it?

Jon