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